From 11ddc3cd04c773b3d6e45872bfa44e43cacacb1f Mon Sep 17 00:00:00 2001 From: haim Date: Tue, 13 Oct 2026 16:28:12 +0300 Subject: [PATCH 1/5] [REFACTOR] Move CoFHE docs under /cofhe with prefixed links and redirects --- .../client-sdk}/examples/end-to-end.mdx | 0 .../client-sdk}/examples/templates.mdx | 0 .../foundry-plugin/cofhe-client.mdx | 8 +- .../client-sdk}/foundry-plugin/cofhe-test.mdx | 10 +- .../foundry-plugin/getting-started.mdx | 12 +- .../client-sdk}/foundry-plugin/testing.mdx | 8 +- .../client-sdk}/guides/acps.mdx | 4 +- .../client-sdk}/guides/client-setup.mdx | 0 .../client-sdk}/guides/decrypt-to-tx.mdx | 12 +- .../client-sdk}/guides/decrypt-to-view.mdx | 10 +- .../client-sdk}/guides/encrypting-inputs.mdx | 4 +- .../client-sdk}/guides/error-handling.mdx | 2 +- .../guides/writing-decrypt-result.mdx | 4 +- .../guides/writing-encrypted-data.mdx | 4 +- .../client-sdk}/hardhat-3-plugin/client.mdx | 8 +- .../hardhat-3-plugin/getting-started.mdx | 12 +- .../client-sdk}/hardhat-3-plugin/logging.mdx | 0 .../hardhat-3-plugin/mock-contracts.mdx | 0 .../client-sdk}/hardhat-3-plugin/testing.mdx | 18 +- .../client-sdk}/hardhat-plugin/client.mdx | 8 +- .../hardhat-plugin/getting-started.mdx | 10 +- .../client-sdk}/hardhat-plugin/logging.mdx | 0 .../hardhat-plugin/mock-contracts.mdx | 0 .../client-sdk}/hardhat-plugin/testing.mdx | 8 +- .../client-sdk}/introduction/installation.mdx | 10 +- .../introduction/mental-model-explorable.mdx | 0 .../client-sdk}/introduction/mental-model.mdx | 6 +- .../client-sdk}/introduction/mental-model.mmd | 0 .../introduction/migrating-from-cofhejs.mdx | 2 +- .../introduction/migrating-to-0-7.mdx | 10 +- .../client-sdk}/introduction/overview.mdx | 14 +- .../client-sdk}/quick-start/foundry.mdx | 8 +- .../client-sdk}/quick-start/hardhat.mdx | 6 +- .../client-sdk}/quick-start/javascript.mdx | 12 +- .../client-sdk}/quick-start/react.mdx | 2 +- .../reference/foundry-reference.mdx | 6 +- .../reference/hardhat-reference.mdx | 0 .../client-sdk}/reference/sdk-reference.mdx | 0 .../deep-dive}/cofhe-components/acl.mdx | 10 +- .../commitment-registry-explorable.mdx | 0 .../cofhe-components/commitment-registry.mdx | 12 +- .../cofhe-components/commitment-registry.mmd | 0 .../cofhe-components/commitment-version.mmd | 0 .../cofhe-components/compute-pipeline.mdx | 8 +- .../cofhe-components/compute-pipeline.mmd | 0 .../key-management-explorable.mdx | 0 .../cofhe-components/key-management.mdx | 8 +- .../cofhe-components/key-management.mmd | 0 cofhe/deep-dive/cofhe-components/overview.mdx | 43 ++ .../deep-dive}/cofhe-components/overview.mmd | 0 .../cofhe-components/plaintext-storage.mdx | 4 +- .../cofhe-components/task-manager.mdx | 6 +- .../teecryptor-explorable.mdx | 0 .../cofhe-components/teecryptor.mdx | 18 +- .../cofhe-components/teecryptor.mmd | 0 .../cofhe-components/verify-commitments.mdx | 10 +- .../cofhe-components/verify-commitments.mmd | 0 .../zk-verifier-explorable.mdx | 0 .../cofhe-components/zk-verifier.mdx | 8 +- .../cofhe-components/zk-verifier.mmd | 0 .../decryption-request-flow-explorable.mdx | 0 .../data-flows/decryption-request-flow.mdx | 14 +- .../data-flows/decryption-request-flow.mmd | 0 .../encryption-request-flow-explorable.mdx | 0 .../data-flows/encryption-request-flow.mdx | 18 +- .../data-flows/encryption-request-flow.mmd | 0 .../fhe-operation-request-flow-explorable.mdx | 0 .../data-flows/fhe-operation-request-flow.mdx | 14 +- .../data-flows/fhe-operation-request-flow.mmd | 0 .../deep-dive}/research/future-plans.mdx | 4 +- .../research/research-in-fhenix.mdx | 2 +- .../calling-from-contracts.mdx | 14 +- .../dual-mode/best-practices.mdx | 16 +- .../dual-mode/confidential-operations.mdx | 12 +- .../dual-mode/dual-balance-model.mdx | 2 +- .../dual-mode/extending.mdx | 6 +- .../dual-mode/overview.mdx | 16 +- .../dual-mode/shield-unshield.mdx | 8 +- .../fherc20/best-practices.mdx | 16 +- .../fherc20/core-features.mdx | 20 +- .../fherc20/fherc20-wrapper.mdx | 10 +- .../fherc20/operators.mdx | 12 +- .../fherc20/overview.mdx | 16 +- .../fherc20/transfer-callbacks.mdx | 10 +- .../confidential-contracts/overview.mdx | 16 +- .../confidential-contracts/upgradeable.mdx | 6 +- .../core-concepts/access-control.mdx | 6 +- .../core-concepts/common-errors.mdx | 22 +- .../fhe-library}/core-concepts/conditions.mdx | 4 +- .../core-concepts/data-evaluation.mdx | 4 +- .../core-concepts/decryption-operations.mdx | 14 +- .../core-concepts/encrypted-operations.mdx | 6 +- .../core-concepts/gas-and-benchmarks.mdx | 6 +- .../fhe-library}/core-concepts/handles.mdx | 12 +- .../fhe-library}/core-concepts/inputs.mdx | 8 +- .../fhe-library}/core-concepts/randomness.mdx | 0 .../fhe-library}/core-concepts/require.mdx | 6 +- .../core-concepts/trivial-encryption.mdx | 2 +- .../fhe-library}/examples/auction-example.mdx | 8 +- .../introduction/best-practices.mdx | 10 +- .../fhe-library}/introduction/overview.mdx | 2 +- .../fhe-library}/introduction/quick-start.mdx | 12 +- .../reference/cofhe-errors-reference.mdx | 2 +- .../fhe-library}/reference/cofhe-errors.mdx | 8 +- .../reference/fhe-sol/access-control.mdx | 0 .../reference/fhe-sol/arithmetic.mdx | 0 .../reference/fhe-sol/bindings.mdx | 0 .../reference/fhe-sol/bitwise.mdx | 0 .../reference/fhe-sol/comparison.mdx | 0 .../reference/fhe-sol/decryption.mdx | 2 +- .../reference/fhe-sol/overview.mdx | 2 +- .../reference/fhe-sol/type-conversion.mdx | 0 .../reference/fhe-sol/utility.mdx | 0 .../fhe-library}/reference/gas-costs.mdx | 2 +- .../build-with-ai/ai-assistant.mdx | 2 +- .../build-with-ai/build-with-ai.mdx | 0 .../introduction/compatibility.mdx | 8 +- .../get-started}/introduction/fhenix.mdx | 0 .../introduction/support-and-feedback.mdx | 6 +- .../introduction/what-is-cofhe-explorable.mdx | 0 .../introduction/what-is-cofhe.mdx | 30 +- .../introduction/what-is-cofhe.mmd | 0 .../images}/commitment-registry.svg | 0 .../images}/commitment-version.svg | 0 {images => cofhe/images}/compute-pipeline.svg | 0 .../images}/decryption-request-flow.svg | 0 .../images}/encryption-request-flow.svg | 0 .../images}/fhe-operation-request-flow.svg | 0 {images => cofhe/images}/key-management.svg | 0 {images => cofhe/images}/mental-model.svg | 0 {images => cofhe/images}/overview.svg | 0 {images => cofhe/images}/teecryptor.svg | 0 .../images}/verify-commitments.svg | 0 {images => cofhe/images}/what-is-cofhe.svg | 0 {images => cofhe/images}/zk-verifier.svg | 0 index.mdx => cofhe/index.mdx | 18 +- .../tutorials}/acl-usage-examples.mdx | 8 +- .../adding-fhe-to-existing-contract.mdx | 12 +- .../tutorials}/migrating-from-fhe-decrypt.mdx | 14 +- {tutorials => cofhe/tutorials}/overview.mdx | 12 +- .../tutorials}/your-first-fhe-contract.mdx | 16 +- deep-dive/cofhe-components/overview.mdx | 43 -- docs.json | 550 +++++++++--------- 143 files changed, 732 insertions(+), 702 deletions(-) rename {client-sdk => cofhe/client-sdk}/examples/end-to-end.mdx (100%) rename {client-sdk => cofhe/client-sdk}/examples/templates.mdx (100%) rename {client-sdk => cofhe/client-sdk}/foundry-plugin/cofhe-client.mdx (94%) rename {client-sdk => cofhe/client-sdk}/foundry-plugin/cofhe-test.mdx (89%) rename {client-sdk => cofhe/client-sdk}/foundry-plugin/getting-started.mdx (84%) rename {client-sdk => cofhe/client-sdk}/foundry-plugin/testing.mdx (95%) rename {client-sdk => cofhe/client-sdk}/guides/acps.mdx (97%) rename {client-sdk => cofhe/client-sdk}/guides/client-setup.mdx (100%) rename {client-sdk => cofhe/client-sdk}/guides/decrypt-to-tx.mdx (89%) rename {client-sdk => cofhe/client-sdk}/guides/decrypt-to-view.mdx (90%) rename {client-sdk => cofhe/client-sdk}/guides/encrypting-inputs.mdx (97%) rename {client-sdk => cofhe/client-sdk}/guides/error-handling.mdx (97%) rename {client-sdk => cofhe/client-sdk}/guides/writing-decrypt-result.mdx (89%) rename {client-sdk => cofhe/client-sdk}/guides/writing-encrypted-data.mdx (93%) rename {client-sdk => cofhe/client-sdk}/hardhat-3-plugin/client.mdx (93%) rename {client-sdk => cofhe/client-sdk}/hardhat-3-plugin/getting-started.mdx (92%) rename {client-sdk => cofhe/client-sdk}/hardhat-3-plugin/logging.mdx (100%) rename {client-sdk => cofhe/client-sdk}/hardhat-3-plugin/mock-contracts.mdx (100%) rename {client-sdk => cofhe/client-sdk}/hardhat-3-plugin/testing.mdx (86%) rename {client-sdk => cofhe/client-sdk}/hardhat-plugin/client.mdx (90%) rename {client-sdk => cofhe/client-sdk}/hardhat-plugin/getting-started.mdx (86%) rename {client-sdk => cofhe/client-sdk}/hardhat-plugin/logging.mdx (100%) rename {client-sdk => cofhe/client-sdk}/hardhat-plugin/mock-contracts.mdx (100%) rename {client-sdk => cofhe/client-sdk}/hardhat-plugin/testing.mdx (90%) rename {client-sdk => cofhe/client-sdk}/introduction/installation.mdx (86%) rename {client-sdk => cofhe/client-sdk}/introduction/mental-model-explorable.mdx (100%) rename {client-sdk => cofhe/client-sdk}/introduction/mental-model.mdx (93%) rename {client-sdk => cofhe/client-sdk}/introduction/mental-model.mmd (100%) rename {client-sdk => cofhe/client-sdk}/introduction/migrating-from-cofhejs.mdx (99%) rename {client-sdk => cofhe/client-sdk}/introduction/migrating-to-0-7.mdx (96%) rename {client-sdk => cofhe/client-sdk}/introduction/overview.mdx (79%) rename {client-sdk => cofhe/client-sdk}/quick-start/foundry.mdx (92%) rename {client-sdk => cofhe/client-sdk}/quick-start/hardhat.mdx (93%) rename {client-sdk => cofhe/client-sdk}/quick-start/javascript.mdx (81%) rename {client-sdk => cofhe/client-sdk}/quick-start/react.mdx (69%) rename {client-sdk => cofhe/client-sdk}/reference/foundry-reference.mdx (94%) rename {client-sdk => cofhe/client-sdk}/reference/hardhat-reference.mdx (100%) rename {client-sdk => cofhe/client-sdk}/reference/sdk-reference.mdx (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/acl.mdx (78%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/commitment-registry-explorable.mdx (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/commitment-registry.mdx (84%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/commitment-registry.mmd (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/commitment-version.mmd (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/compute-pipeline.mdx (83%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/compute-pipeline.mmd (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/key-management-explorable.mdx (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/key-management.mdx (88%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/key-management.mmd (100%) create mode 100644 cofhe/deep-dive/cofhe-components/overview.mdx rename {deep-dive => cofhe/deep-dive}/cofhe-components/overview.mmd (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/plaintext-storage.mdx (74%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/task-manager.mdx (86%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/teecryptor-explorable.mdx (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/teecryptor.mdx (78%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/teecryptor.mmd (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/verify-commitments.mdx (91%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/verify-commitments.mmd (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/zk-verifier-explorable.mdx (100%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/zk-verifier.mdx (87%) rename {deep-dive => cofhe/deep-dive}/cofhe-components/zk-verifier.mmd (100%) rename {deep-dive => cofhe/deep-dive}/data-flows/decryption-request-flow-explorable.mdx (100%) rename {deep-dive => cofhe/deep-dive}/data-flows/decryption-request-flow.mdx (80%) rename {deep-dive => cofhe/deep-dive}/data-flows/decryption-request-flow.mmd (100%) rename {deep-dive => cofhe/deep-dive}/data-flows/encryption-request-flow-explorable.mdx (100%) rename {deep-dive => cofhe/deep-dive}/data-flows/encryption-request-flow.mdx (70%) rename {deep-dive => cofhe/deep-dive}/data-flows/encryption-request-flow.mmd (100%) rename {deep-dive => cofhe/deep-dive}/data-flows/fhe-operation-request-flow-explorable.mdx (100%) rename {deep-dive => cofhe/deep-dive}/data-flows/fhe-operation-request-flow.mdx (72%) rename {deep-dive => cofhe/deep-dive}/data-flows/fhe-operation-request-flow.mmd (100%) rename {deep-dive => cofhe/deep-dive}/research/future-plans.mdx (89%) rename {deep-dive => cofhe/deep-dive}/research/research-in-fhenix.mdx (78%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/calling-from-contracts.mdx (85%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/dual-mode/best-practices.mdx (75%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/dual-mode/confidential-operations.mdx (82%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/dual-mode/dual-balance-model.mdx (98%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/dual-mode/extending.mdx (95%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/dual-mode/overview.mdx (77%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/dual-mode/shield-unshield.mdx (84%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/fherc20/best-practices.mdx (81%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/fherc20/core-features.mdx (85%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/fherc20/fherc20-wrapper.mdx (93%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/fherc20/operators.mdx (77%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/fherc20/overview.mdx (82%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/fherc20/transfer-callbacks.mdx (88%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/overview.mdx (88%) rename {fhe-library => cofhe/fhe-library}/confidential-contracts/upgradeable.mdx (94%) rename {fhe-library => cofhe/fhe-library}/core-concepts/access-control.mdx (96%) rename {fhe-library => cofhe/fhe-library}/core-concepts/common-errors.mdx (84%) rename {fhe-library => cofhe/fhe-library}/core-concepts/conditions.mdx (97%) rename {fhe-library => cofhe/fhe-library}/core-concepts/data-evaluation.mdx (96%) rename {fhe-library => cofhe/fhe-library}/core-concepts/decryption-operations.mdx (94%) rename {fhe-library => cofhe/fhe-library}/core-concepts/encrypted-operations.mdx (96%) rename {fhe-library => cofhe/fhe-library}/core-concepts/gas-and-benchmarks.mdx (65%) rename {fhe-library => cofhe/fhe-library}/core-concepts/handles.mdx (87%) rename {fhe-library => cofhe/fhe-library}/core-concepts/inputs.mdx (93%) rename {fhe-library => cofhe/fhe-library}/core-concepts/randomness.mdx (100%) rename {fhe-library => cofhe/fhe-library}/core-concepts/require.mdx (78%) rename {fhe-library => cofhe/fhe-library}/core-concepts/trivial-encryption.mdx (96%) rename {fhe-library => cofhe/fhe-library}/examples/auction-example.mdx (96%) rename {fhe-library => cofhe/fhe-library}/introduction/best-practices.mdx (95%) rename {fhe-library => cofhe/fhe-library}/introduction/overview.mdx (98%) rename {fhe-library => cofhe/fhe-library}/introduction/quick-start.mdx (94%) rename {fhe-library => cofhe/fhe-library}/reference/cofhe-errors-reference.mdx (99%) rename {fhe-library => cofhe/fhe-library}/reference/cofhe-errors.mdx (92%) rename {fhe-library => cofhe/fhe-library}/reference/fhe-sol/access-control.mdx (100%) rename {fhe-library => cofhe/fhe-library}/reference/fhe-sol/arithmetic.mdx (100%) rename {fhe-library => cofhe/fhe-library}/reference/fhe-sol/bindings.mdx (100%) rename {fhe-library => cofhe/fhe-library}/reference/fhe-sol/bitwise.mdx (100%) rename {fhe-library => cofhe/fhe-library}/reference/fhe-sol/comparison.mdx (100%) rename {fhe-library => cofhe/fhe-library}/reference/fhe-sol/decryption.mdx (96%) rename {fhe-library => cofhe/fhe-library}/reference/fhe-sol/overview.mdx (97%) rename {fhe-library => cofhe/fhe-library}/reference/fhe-sol/type-conversion.mdx (100%) rename {fhe-library => cofhe/fhe-library}/reference/fhe-sol/utility.mdx (100%) rename {fhe-library => cofhe/fhe-library}/reference/gas-costs.mdx (97%) rename {get-started => cofhe/get-started}/build-with-ai/ai-assistant.mdx (98%) rename {get-started => cofhe/get-started}/build-with-ai/build-with-ai.mdx (100%) rename {get-started => cofhe/get-started}/introduction/compatibility.mdx (91%) rename {get-started => cofhe/get-started}/introduction/fhenix.mdx (100%) rename {get-started => cofhe/get-started}/introduction/support-and-feedback.mdx (92%) rename {get-started => cofhe/get-started}/introduction/what-is-cofhe-explorable.mdx (100%) rename {get-started => cofhe/get-started}/introduction/what-is-cofhe.mdx (65%) rename {get-started => cofhe/get-started}/introduction/what-is-cofhe.mmd (100%) rename {images => cofhe/images}/commitment-registry.svg (100%) rename {images => cofhe/images}/commitment-version.svg (100%) rename {images => cofhe/images}/compute-pipeline.svg (100%) rename {images => cofhe/images}/decryption-request-flow.svg (100%) rename {images => cofhe/images}/encryption-request-flow.svg (100%) rename {images => cofhe/images}/fhe-operation-request-flow.svg (100%) rename {images => cofhe/images}/key-management.svg (100%) rename {images => cofhe/images}/mental-model.svg (100%) rename {images => cofhe/images}/overview.svg (100%) rename {images => cofhe/images}/teecryptor.svg (100%) rename {images => cofhe/images}/verify-commitments.svg (100%) rename {images => cofhe/images}/what-is-cofhe.svg (100%) rename {images => cofhe/images}/zk-verifier.svg (100%) rename index.mdx => cofhe/index.mdx (61%) rename {tutorials => cofhe/tutorials}/acl-usage-examples.mdx (94%) rename {tutorials => cofhe/tutorials}/adding-fhe-to-existing-contract.mdx (97%) rename {tutorials => cofhe/tutorials}/migrating-from-fhe-decrypt.mdx (92%) rename {tutorials => cofhe/tutorials}/overview.mdx (52%) rename {tutorials => cofhe/tutorials}/your-first-fhe-contract.mdx (91%) delete mode 100644 deep-dive/cofhe-components/overview.mdx diff --git a/client-sdk/examples/end-to-end.mdx b/cofhe/client-sdk/examples/end-to-end.mdx similarity index 100% rename from client-sdk/examples/end-to-end.mdx rename to cofhe/client-sdk/examples/end-to-end.mdx diff --git a/client-sdk/examples/templates.mdx b/cofhe/client-sdk/examples/templates.mdx similarity index 100% rename from client-sdk/examples/templates.mdx rename to cofhe/client-sdk/examples/templates.mdx diff --git a/client-sdk/foundry-plugin/cofhe-client.mdx b/cofhe/client-sdk/foundry-plugin/cofhe-client.mdx similarity index 94% rename from client-sdk/foundry-plugin/cofhe-client.mdx rename to cofhe/client-sdk/foundry-plugin/cofhe-client.mdx index b4640602..46cc88f3 100644 --- a/client-sdk/foundry-plugin/cofhe-client.mdx +++ b/cofhe/client-sdk/foundry-plugin/cofhe-client.mdx @@ -7,7 +7,7 @@ description: "The in-Solidity SDK shim: one client per user, produces encrypted ## Creating and connecting -Spin up a client from inside [`CofheTest`](/client-sdk/foundry-plugin/cofhe-test) with `createCofheClient()`, then bind it to an address with `connect(pkey)`: +Spin up a client from inside [`CofheTest`](/cofhe/client-sdk/foundry-plugin/cofhe-test) with `createCofheClient()`, then bind it to an address with `connect(pkey)`: ```solidity CofheClient bob = createCofheClient(); @@ -91,7 +91,7 @@ uint256 value = bob.decryptForView(ctHash, bobAcp); assertEq(value, 42); ``` -`decryptForView` reverts when the caller isn't on the ACL. To **assert** the deny path (e.g. "Alice should NOT be able to decrypt Bob's value"), drop down to the mock directly. See [Testing: Deny path](/client-sdk/foundry-plugin/testing#deny-path). +`decryptForView` reverts when the caller isn't on the ACL. To **assert** the deny path (e.g. "Alice should NOT be able to decrypt Bob's value"), drop down to the mock directly. See [Testing: Deny path](/cofhe/client-sdk/foundry-plugin/testing#deny-path). ## Access Control Permissions @@ -169,5 +169,5 @@ assertEq(err, "NotAllowed"); ## Next steps -- [Testing](/client-sdk/foundry-plugin/testing): full test-writing patterns. -- [CofheTest](/client-sdk/foundry-plugin/cofhe-test): the test base contract that creates clients. +- [Testing](/cofhe/client-sdk/foundry-plugin/testing): full test-writing patterns. +- [CofheTest](/cofhe/client-sdk/foundry-plugin/cofhe-test): the test base contract that creates clients. diff --git a/client-sdk/foundry-plugin/cofhe-test.mdx b/cofhe/client-sdk/foundry-plugin/cofhe-test.mdx similarity index 89% rename from client-sdk/foundry-plugin/cofhe-test.mdx rename to cofhe/client-sdk/foundry-plugin/cofhe-test.mdx index e1cde3cc..b9009319 100644 --- a/client-sdk/foundry-plugin/cofhe-test.mdx +++ b/cofhe/client-sdk/foundry-plugin/cofhe-test.mdx @@ -42,11 +42,11 @@ mockThresholdNetwork mockThresholdNetworkSigner ``` -Reach into them when you need behavior `expectPlaintext` doesn't cover (e.g. permission-denied assertions: see [Testing](/client-sdk/foundry-plugin/testing#deny-path)). +Reach into them when you need behavior `expectPlaintext` doesn't cover (e.g. permission-denied assertions: see [Testing](/cofhe/client-sdk/foundry-plugin/testing#deny-path)). ## `createCofheClient()` -Returns a fresh [`CofheClient`](/client-sdk/foundry-plugin/cofhe-client). You typically follow it with `connect(pkey)`: +Returns a fresh [`CofheClient`](/cofhe/client-sdk/foundry-plugin/cofhe-client). You typically follow it with `connect(pkey)`: ```solidity CofheClient bob = createCofheClient(); @@ -130,7 +130,7 @@ That import path is the **old** API from `@cofhe/mock-contracts@0.4.x`. Migrate import { CofheTest } from "@cofhe/foundry-plugin/contracts/CofheTest.sol"; ``` -See the [migration mapping](/client-sdk/foundry-plugin/testing#migration-from-the-old-mock-contracts-api) for the full rename table. +See the [migration mapping](/cofhe/client-sdk/foundry-plugin/testing#migration-from-the-old-mock-contracts-api) for the full rename table. @@ -140,5 +140,5 @@ The remappings are relative to the foundry package's root. Running `forge test` ## Next steps -- [CofheClient](/client-sdk/foundry-plugin/cofhe-client): per-user encrypt, decrypt, and ACP shim. -- [Testing](/client-sdk/foundry-plugin/testing): canonical test-writing patterns and migration mapping. +- [CofheClient](/cofhe/client-sdk/foundry-plugin/cofhe-client): per-user encrypt, decrypt, and ACP shim. +- [Testing](/cofhe/client-sdk/foundry-plugin/testing): canonical test-writing patterns and migration mapping. diff --git a/client-sdk/foundry-plugin/getting-started.mdx b/cofhe/client-sdk/foundry-plugin/getting-started.mdx similarity index 84% rename from client-sdk/foundry-plugin/getting-started.mdx rename to cofhe/client-sdk/foundry-plugin/getting-started.mdx index 9b80551d..c2cd63b1 100644 --- a/client-sdk/foundry-plugin/getting-started.mdx +++ b/cofhe/client-sdk/foundry-plugin/getting-started.mdx @@ -3,7 +3,7 @@ title: Getting Started description: "Set up @cofhe/foundry-plugin for local FHE contract development and testing under Forge" --- -`@cofhe/foundry-plugin` is the Foundry counterpart to [`@cofhe/hardhat-plugin`](/client-sdk/hardhat-plugin/getting-started). It provides two abstract Solidity contracts, `CofheTest` (test base, deploys all CoFHE mocks) and `CofheClient` (per-account encrypt, decrypt, and ACP shim), that let you exercise FHE contracts under `forge test` with **no JS SDK required**. +`@cofhe/foundry-plugin` is the Foundry counterpart to [`@cofhe/hardhat-plugin`](/cofhe/client-sdk/hardhat-plugin/getting-started). It provides two abstract Solidity contracts, `CofheTest` (test base, deploys all CoFHE mocks) and `CofheClient` (per-account encrypt, decrypt, and ACP shim), that let you exercise FHE contracts under `forge test` with **no JS SDK required**. Want to skip the setup? Clone the [cofhe-foundry-starter](https://github.com/FhenixProtocol/cofhe-foundry-starter) template to get a pre-configured project ready to go. @@ -133,11 +133,11 @@ Known-aligned tuple as of writing: | `@cofhe/mock-contracts` | `0.8.0` | | `@fhenixprotocol/cofhe-contracts` | `1.0.0` | -See the [Compatibility](/get-started/introduction/compatibility) page for the canonical table. +See the [Compatibility](/cofhe/get-started/introduction/compatibility) page for the canonical table. ## Mocks vs production -The mocks are the same `@cofhe/mock-contracts` package the [Hardhat plugin](/client-sdk/hardhat-plugin/mock-contracts) uses. Behaviorally: +The mocks are the same `@cofhe/mock-contracts` package the [Hardhat plugin](/cofhe/client-sdk/hardhat-plugin/mock-contracts) uses. Behaviorally: - Plaintext lives onchain in `MockTaskManager.mockStorage` (so `expectPlaintext` and `getPlaintext` work). - No real ZK proving; encrypted inputs are signed by `MockZkVerifierSigner`. @@ -148,6 +148,6 @@ The same test code runs unchanged against real CoFHE on a deployed network. ## Next steps -- [CofheTest](/client-sdk/foundry-plugin/cofhe-test): the test base contract: `deployMocks`, `expectPlaintext`, `getPlaintext`, log toggles. -- [CofheClient](/client-sdk/foundry-plugin/cofhe-client): per-user shim: `createExternalEuintN`, `decryptForTx_withoutACP`, `decryptForView`, ACPs. -- [Testing](/client-sdk/foundry-plugin/testing): canonical test patterns and the migration mapping from the old `@cofhe/mock-contracts/foundry/CoFheTest.sol` API. +- [CofheTest](/cofhe/client-sdk/foundry-plugin/cofhe-test): the test base contract: `deployMocks`, `expectPlaintext`, `getPlaintext`, log toggles. +- [CofheClient](/cofhe/client-sdk/foundry-plugin/cofhe-client): per-user shim: `createExternalEuintN`, `decryptForTx_withoutACP`, `decryptForView`, ACPs. +- [Testing](/cofhe/client-sdk/foundry-plugin/testing): canonical test patterns and the migration mapping from the old `@cofhe/mock-contracts/foundry/CoFheTest.sol` API. diff --git a/client-sdk/foundry-plugin/testing.mdx b/cofhe/client-sdk/foundry-plugin/testing.mdx similarity index 95% rename from client-sdk/foundry-plugin/testing.mdx rename to cofhe/client-sdk/foundry-plugin/testing.mdx index ea474061..2fc432b4 100644 --- a/client-sdk/foundry-plugin/testing.mdx +++ b/cofhe/client-sdk/foundry-plugin/testing.mdx @@ -3,7 +3,7 @@ title: Testing description: "Canonical test-writing patterns for FHE contracts under Foundry" --- -This page shows the load-bearing patterns for writing FHE contract tests under Foundry with `@cofhe/foundry-plugin`. Hardhat counterpart: [Hardhat Plugin: Testing](/client-sdk/hardhat-plugin/testing). +This page shows the load-bearing patterns for writing FHE contract tests under Foundry with `@cofhe/foundry-plugin`. Hardhat counterpart: [Hardhat Plugin: Testing](/cofhe/client-sdk/hardhat-plugin/testing). ## Skeleton @@ -189,6 +189,6 @@ The `pkey` passed to `connect` must derive the address used as `acp.issuer`. `bo ## Related -- [CofheTest](/client-sdk/foundry-plugin/cofhe-test): the test base contract API. -- [CofheClient](/client-sdk/foundry-plugin/cofhe-client): the per-user shim API. -- [Testing under Hardhat](/client-sdk/hardhat-plugin/testing): the same patterns for Hardhat. +- [CofheTest](/cofhe/client-sdk/foundry-plugin/cofhe-test): the test base contract API. +- [CofheClient](/cofhe/client-sdk/foundry-plugin/cofhe-client): the per-user shim API. +- [Testing under Hardhat](/cofhe/client-sdk/hardhat-plugin/testing): the same patterns for Hardhat. diff --git a/client-sdk/guides/acps.mdx b/cofhe/client-sdk/guides/acps.mdx similarity index 97% rename from client-sdk/guides/acps.mdx rename to cofhe/client-sdk/guides/acps.mdx index 9202f7e0..e39ef387 100644 --- a/client-sdk/guides/acps.mdx +++ b/cofhe/client-sdk/guides/acps.mdx @@ -8,7 +8,7 @@ An Access Control Permission (ACP) is an EIP-712 signature that authorizes decry Every ACP carries a sealing keypair. The public key goes to CoFHE so it can seal the result to the holder. The private key stays on the client and unseals the value when it comes back. -ACPs were called permits before `0.7`. The name changed so they are not confused with an ERC-2612 permit, which is a different thing entirely. If you are upgrading, see [migrating to 0.7](/client-sdk/introduction/migrating-to-0-7). This page uses "ACP" throughout. +ACPs were called permits before `0.7`. The name changed so they are not confused with an ERC-2612 permit, which is a different thing entirely. If you are upgrading, see [migrating to 0.7](/cofhe/client-sdk/introduction/migrating-to-0-7). This page uses "ACP" throughout. ## When you need one @@ -18,7 +18,7 @@ ACPs were called permits before `0.7`. The name changed so they are not confused ## Prerequisites -[Create and connect a client](/client-sdk/guides/client-setup). ACPs are scoped to a chainId and account pair. +[Create and connect a client](/cofhe/client-sdk/guides/client-setup). ACPs are scoped to a chainId and account pair. ## Quick start diff --git a/client-sdk/guides/client-setup.mdx b/cofhe/client-sdk/guides/client-setup.mdx similarity index 100% rename from client-sdk/guides/client-setup.mdx rename to cofhe/client-sdk/guides/client-setup.mdx diff --git a/client-sdk/guides/decrypt-to-tx.mdx b/cofhe/client-sdk/guides/decrypt-to-tx.mdx similarity index 89% rename from client-sdk/guides/decrypt-to-tx.mdx rename to cofhe/client-sdk/guides/decrypt-to-tx.mdx index 3b3e9851..cb05b119 100644 --- a/client-sdk/guides/decrypt-to-tx.mdx +++ b/cofhe/client-sdk/guides/decrypt-to-tx.mdx @@ -3,7 +3,7 @@ title: Decrypt to Transact description: "Decrypt with a verifiable Teecryptor signature for onchain use" --- -Use `decryptForTx` to reveal a confidential (encrypted) value onchain. It returns the plaintext together with a [Teecryptor](/deep-dive/cofhe-components/teecryptor) signature, so a contract can verify the reveal when you publish it in a transaction. +Use `decryptForTx` to reveal a confidential (encrypted) value onchain. It returns the plaintext together with a [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) signature, so a contract can verify the reveal when you publish it in a transaction. Common use cases: @@ -11,17 +11,17 @@ Common use cases: - **Finalize a private auction / game move**: bids or moves are submitted encrypted, and the winner is revealed later in a verifiable way. -If you only need to show plaintext in your UI (and you do **not** need an onchain-verifiable signature), use [`decryptForView`](/client-sdk/guides/decrypt-to-view) instead. +If you only need to show plaintext in your UI (and you do **not** need an onchain-verifiable signature), use [`decryptForView`](/cofhe/client-sdk/guides/decrypt-to-view) instead. ## Prerequisites -1. [Create and connect a client](/client-sdk/guides/client-setup). +1. [Create and connect a client](/cofhe/client-sdk/guides/client-setup). 2. Know the onchain encrypted handle (`ctHash`) you want to decrypt. -3. Determine whether the contract's ACL policy for this `ctHash` requires a [ACP](/client-sdk/guides/acps). +3. Determine whether the contract's ACL policy for this `ctHash` requires a [ACP](/cofhe/client-sdk/guides/acps). -`decryptForTx` does not take a `utype`. It always returns the plaintext as a `bigint` because the result is intended to be passed into a transaction. If you need UI-friendly decoding, use [`decryptForView`](/client-sdk/guides/decrypt-to-view). +`decryptForTx` does not take a `utype`. It always returns the plaintext as a `bigint` because the result is intended to be passed into a transaction. If you need UI-friendly decoding, use [`decryptForView`](/cofhe/client-sdk/guides/decrypt-to-view). ## ACP: when is it needed? @@ -74,7 +74,7 @@ const decryptResult = await client -After decrypting, see [Writing Decrypt Result to Contract](/client-sdk/guides/writing-decrypt-result) for how to publish or verify the result onchain. +After decrypting, see [Writing Decrypt Result to Contract](/cofhe/client-sdk/guides/writing-decrypt-result) for how to publish or verify the result onchain. ## Builder API diff --git a/client-sdk/guides/decrypt-to-view.mdx b/cofhe/client-sdk/guides/decrypt-to-view.mdx similarity index 90% rename from client-sdk/guides/decrypt-to-view.mdx rename to cofhe/client-sdk/guides/decrypt-to-view.mdx index ac3cae13..8e37b9a2 100644 --- a/client-sdk/guides/decrypt-to-view.mdx +++ b/cofhe/client-sdk/guides/decrypt-to-view.mdx @@ -5,7 +5,7 @@ description: "Reveal encrypted values locally for UI display using ACPs" Use `decryptForView` to reveal a confidential (encrypted) value locally in your app so you can display it in the UI. -Unlike [`decryptForTx`](/client-sdk/guides/decrypt-to-tx), this flow does **not** return an onchain-verifiable signature, and it is **not** meant to be published onchain. +Unlike [`decryptForTx`](/cofhe/client-sdk/guides/decrypt-to-tx), this flow does **not** return an onchain-verifiable signature, and it is **not** meant to be published onchain. ## Flow @@ -14,14 +14,14 @@ Unlike [`decryptForTx`](/client-sdk/guides/decrypt-to-tx), this flow does **not* 3. Call `decryptForView(ctHash, utype).execute()` to get the plaintext. -`decryptForView` always decrypts using an ACP (there is no `.withoutACP()` mode). If your protocol intends for the plaintext to become publicly visible onchain, use [`decryptForTx`](/client-sdk/guides/decrypt-to-tx) instead. +`decryptForView` always decrypts using an ACP (there is no `.withoutACP()` mode). If your protocol intends for the plaintext to become publicly visible onchain, use [`decryptForTx`](/cofhe/client-sdk/guides/decrypt-to-tx) instead. ## Prerequisites -1. [Create and connect a client](/client-sdk/guides/client-setup). +1. [Create and connect a client](/cofhe/client-sdk/guides/client-setup). 2. Know the encrypted handle (`ctHash`) and the encrypted type (`utype`). -3. Have a [ACP](/client-sdk/guides/acps) available for the connected `chainId + account`. +3. Have a [ACP](/cofhe/client-sdk/guides/acps) available for the connected `chainId + account`. **Getting `ctHash`**: In most apps, `ctHash` comes from reading a stored encrypted value, an event arg, or a return value from a `view` call. @@ -110,7 +110,7 @@ Overrides the account used to resolve the active/stored ACP. ### `.setChainId(chainId)` (optional) -Overrides the chain used to resolve the [Teecryptor](/deep-dive/cofhe-components/teecryptor) URL and ACPs. +Overrides the chain used to resolve the [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) URL and ACPs. ### `.onPoll(callback)` (optional) diff --git a/client-sdk/guides/encrypting-inputs.mdx b/cofhe/client-sdk/guides/encrypting-inputs.mdx similarity index 97% rename from client-sdk/guides/encrypting-inputs.mdx rename to cofhe/client-sdk/guides/encrypting-inputs.mdx index 82529afb..69cf6442 100644 --- a/client-sdk/guides/encrypting-inputs.mdx +++ b/cofhe/client-sdk/guides/encrypting-inputs.mdx @@ -9,7 +9,7 @@ One call produces one batch: a ciphertext handle for each value, plus a single s ## Prerequisites -1. [Create and connect a client](/client-sdk/guides/client-setup). +1. [Create and connect a client](/cofhe/client-sdk/guides/client-setup). 2. Know which encrypted type each value needs. It must match the Solidity parameter your contract declares, for example `externalEuint32` against `externalEuint64`. 3. Know the address of the contract that will consume the inputs. You have to declare it before signing. @@ -82,7 +82,7 @@ await contract.transfer(recipient, [amountHash, feeHash], signature); ``` -The signature does not have to be the last parameter, and encrypted parameters must be adjacent to each other because they share one signature. See [migrating to 0.7](/client-sdk/introduction/migrating-to-0-7) for the Solidity side. +The signature does not have to be the last parameter, and encrypted parameters must be adjacent to each other because they share one signature. See [migrating to 0.7](/cofhe/client-sdk/introduction/migrating-to-0-7) for the Solidity side. ## Builder API diff --git a/client-sdk/guides/error-handling.mdx b/cofhe/client-sdk/guides/error-handling.mdx similarity index 97% rename from client-sdk/guides/error-handling.mdx rename to cofhe/client-sdk/guides/error-handling.mdx index ce7fcd66..1e5b505d 100644 --- a/client-sdk/guides/error-handling.mdx +++ b/cofhe/client-sdk/guides/error-handling.mdx @@ -147,7 +147,7 @@ const plaintext = await client .execute(); ``` -`ValidationResult.error` is the typed union `'invalid-schema' | 'expired' | 'not-signed' | null`. See [validating ACPs](/client-sdk/guides/acps#validating) for the full helper surface. +`ValidationResult.error` is the typed union `'invalid-schema' | 'expired' | 'not-signed' | null`. See [validating ACPs](/cofhe/client-sdk/guides/acps#validating) for the full helper surface. If you prefer the throwing path: `ACPUtils.validate(acp)` raises plain `Error`s with messages `ACP is expired` / `ACP is not signed` (or a Zod schema error). These are not wrapped in `CofheError`, so use `err.message` rather than an error code to branch. diff --git a/client-sdk/guides/writing-decrypt-result.mdx b/cofhe/client-sdk/guides/writing-decrypt-result.mdx similarity index 89% rename from client-sdk/guides/writing-decrypt-result.mdx rename to cofhe/client-sdk/guides/writing-decrypt-result.mdx index 25e27b25..0949b220 100644 --- a/client-sdk/guides/writing-decrypt-result.mdx +++ b/cofhe/client-sdk/guides/writing-decrypt-result.mdx @@ -3,7 +3,7 @@ title: Writing Decrypt Result to Contract description: "Submit a decryptForTx result onchain for verification or publishing" --- -This page covers the "decrypt to write tx" flow after you run [`decryptForTx`](/client-sdk/guides/decrypt-to-tx): you take `{ ctHash, decryptedValue, signature }` and submit a transaction that your contract can verify. +This page covers the "decrypt to write tx" flow after you run [`decryptForTx`](/cofhe/client-sdk/guides/decrypt-to-tx): you take `{ ctHash, decryptedValue, signature }` and submit a transaction that your contract can verify. There are two common patterns: @@ -12,7 +12,7 @@ There are two common patterns: ## Prerequisites -1. Run [`decryptForTx`](/client-sdk/guides/decrypt-to-tx) and get a result object with `ctHash`, `decryptedValue`, and `signature`. +1. Run [`decryptForTx`](/cofhe/client-sdk/guides/decrypt-to-tx) and get a result object with `ctHash`, `decryptedValue`, and `signature`. 2. Ensure the Solidity parameter type matches your encrypted type. diff --git a/client-sdk/guides/writing-encrypted-data.mdx b/cofhe/client-sdk/guides/writing-encrypted-data.mdx similarity index 93% rename from client-sdk/guides/writing-encrypted-data.mdx rename to cofhe/client-sdk/guides/writing-encrypted-data.mdx index 15a0d0b5..52e5134f 100644 --- a/client-sdk/guides/writing-encrypted-data.mdx +++ b/cofhe/client-sdk/guides/writing-encrypted-data.mdx @@ -10,12 +10,12 @@ This page covers the "encrypt to write tx" flow: encrypt plaintext values and pa ## Flow 1. Ensure your contract function accepts an `externalEuintXX` handle plus a `bytes` proof. -2. Encrypt the plaintext values with [`encryptInputs`](/client-sdk/guides/encrypting-inputs), naming the contract that will consume them. +2. Encrypt the plaintext values with [`encryptInputs`](/cofhe/client-sdk/guides/encrypting-inputs), naming the contract that will consume them. 3. Send a transaction, passing the handle and the proof. ## Prerequisites -1. [Create and connect a client](/client-sdk/guides/client-setup). +1. [Create and connect a client](/cofhe/client-sdk/guides/client-setup). 2. Your contract function must accept `externalEuintXX` parameters with a `bytes` proof. The encrypted type you choose in TypeScript must match the Solidity parameter type: diff --git a/client-sdk/hardhat-3-plugin/client.mdx b/cofhe/client-sdk/hardhat-3-plugin/client.mdx similarity index 93% rename from client-sdk/hardhat-3-plugin/client.mdx rename to cofhe/client-sdk/hardhat-3-plugin/client.mdx index b619f800..e5695f47 100644 --- a/client-sdk/hardhat-3-plugin/client.mdx +++ b/cofhe/client-sdk/hardhat-3-plugin/client.mdx @@ -102,7 +102,7 @@ An encrypted input is bound to the account that encrypted it. Send the transacti Once connected, the client is the standard SDK client. See: -- [Encrypting inputs](/client-sdk/guides/encrypting-inputs) -- [Decrypt to view](/client-sdk/guides/decrypt-to-view) -- [Decrypt to transact](/client-sdk/guides/decrypt-to-tx) -- [Access Control Permissions](/client-sdk/guides/acps) +- [Encrypting inputs](/cofhe/client-sdk/guides/encrypting-inputs) +- [Decrypt to view](/cofhe/client-sdk/guides/decrypt-to-view) +- [Decrypt to transact](/cofhe/client-sdk/guides/decrypt-to-tx) +- [Access Control Permissions](/cofhe/client-sdk/guides/acps) diff --git a/client-sdk/hardhat-3-plugin/getting-started.mdx b/cofhe/client-sdk/hardhat-3-plugin/getting-started.mdx similarity index 92% rename from client-sdk/hardhat-3-plugin/getting-started.mdx rename to cofhe/client-sdk/hardhat-3-plugin/getting-started.mdx index 77253c86..4863c7e8 100644 --- a/client-sdk/hardhat-3-plugin/getting-started.mdx +++ b/cofhe/client-sdk/hardhat-3-plugin/getting-started.mdx @@ -6,7 +6,7 @@ description: "Install and configure @cofhe/hardhat-3-plugin for local FHE contra `@cofhe/hardhat-3-plugin` runs the CoFHE mock contracts inside Hardhat 3's simulated network and attaches a `cofhe` object to every network connection. Use it to compile, test, and debug FHE contracts locally without the offchain CoFHE services. -This plugin is for Hardhat 3. For a Hardhat 2 project, use [`@cofhe/hardhat-plugin`](/client-sdk/hardhat-plugin/getting-started). The two are not interchangeable. +This plugin is for Hardhat 3. For a Hardhat 2 project, use [`@cofhe/hardhat-plugin`](/cofhe/client-sdk/hardhat-plugin/getting-started). The two are not interchangeable. ## What the plugin provides @@ -149,7 +149,7 @@ export default defineConfig({ | mocksDeployVerbosity | `'' \| 'v' \| 'vv'` | `'v'` | Output while the mocks deploy. `''` prints nothing, `'v'` prints one summary line, `'vv'` prints each contract and its address. | -The config type also accepts `cofhe.logMocks`, but no plugin code reads it. Setting it has no effect on FHE operation logs. Use the helpers on the [Logging](/client-sdk/hardhat-3-plugin/logging) page instead. +The config type also accepts `cofhe.logMocks`, but no plugin code reads it. Setting it has no effect on FHE operation logs. Use the helpers on the [Logging](/cofhe/client-sdk/hardhat-3-plugin/logging) page instead. ## When the mocks deploy @@ -202,7 +202,7 @@ The mock contracts themselves are the same package, `@cofhe/mock-contracts`, in ## Next steps -- [Client](/client-sdk/hardhat-3-plugin/client): create and connect an SDK client in a test. -- [Mock contracts](/client-sdk/hardhat-3-plugin/mock-contracts): read plaintext values and call the mocks directly. -- [Logging](/client-sdk/hardhat-3-plugin/logging): print the FHE operations your contracts perform. -- [Testing](/client-sdk/hardhat-3-plugin/testing): a complete test file and the patterns around it. +- [Client](/cofhe/client-sdk/hardhat-3-plugin/client): create and connect an SDK client in a test. +- [Mock contracts](/cofhe/client-sdk/hardhat-3-plugin/mock-contracts): read plaintext values and call the mocks directly. +- [Logging](/cofhe/client-sdk/hardhat-3-plugin/logging): print the FHE operations your contracts perform. +- [Testing](/cofhe/client-sdk/hardhat-3-plugin/testing): a complete test file and the patterns around it. diff --git a/client-sdk/hardhat-3-plugin/logging.mdx b/cofhe/client-sdk/hardhat-3-plugin/logging.mdx similarity index 100% rename from client-sdk/hardhat-3-plugin/logging.mdx rename to cofhe/client-sdk/hardhat-3-plugin/logging.mdx diff --git a/client-sdk/hardhat-3-plugin/mock-contracts.mdx b/cofhe/client-sdk/hardhat-3-plugin/mock-contracts.mdx similarity index 100% rename from client-sdk/hardhat-3-plugin/mock-contracts.mdx rename to cofhe/client-sdk/hardhat-3-plugin/mock-contracts.mdx diff --git a/client-sdk/hardhat-3-plugin/testing.mdx b/cofhe/client-sdk/hardhat-3-plugin/testing.mdx similarity index 86% rename from client-sdk/hardhat-3-plugin/testing.mdx rename to cofhe/client-sdk/hardhat-3-plugin/testing.mdx index 0e3094b3..0f34920f 100644 --- a/client-sdk/hardhat-3-plugin/testing.mdx +++ b/cofhe/client-sdk/hardhat-3-plugin/testing.mdx @@ -3,7 +3,7 @@ title: Testing description: "A complete Hardhat 3 test for an FHE contract, and the patterns around it" --- -This page builds one test file for an encrypted counter. It then covers the patterns you add as a contract grows: plaintext assertions, ACPs (Access Control Permissions), and decryption for a transaction. It assumes the setup from [Getting Started](/client-sdk/hardhat-3-plugin/getting-started). +This page builds one test file for an encrypted counter. It then covers the patterns you add as a contract grows: plaintext assertions, ACPs (Access Control Permissions), and decryption for a transaction. It assumes the setup from [Getting Started](/cofhe/client-sdk/hardhat-3-plugin/getting-started). ## The contract @@ -110,7 +110,7 @@ await counter.write.increment(); await cofhe.mocks.expectPlaintext(await counter.read.count(), 43n); ``` -Use `decryptForView` when the SDK's own behavior is under test. See [Mock contracts](/client-sdk/hardhat-3-plugin/mock-contracts) for both plaintext helpers. +Use `decryptForView` when the SDK's own behavior is under test. See [Mock contracts](/cofhe/client-sdk/hardhat-3-plugin/mock-contracts) for both plaintext helpers. ## Named ACPs @@ -127,11 +127,11 @@ const acp = await client.acp.createSelf({ client.acp.selectActiveACP(ACPUtils.getHash(acp)); ``` -For several signers, create one client per wallet, as shown on the [Client](/client-sdk/hardhat-3-plugin/client#several-signers) page. +For several signers, create one client per wallet, as shown on the [Client](/cofhe/client-sdk/hardhat-3-plugin/client#several-signers) page. ## Decrypt for a transaction -[`decryptForTx`](/client-sdk/guides/decrypt-to-tx) resolves to `{ ctHash, decryptedValue, signature }`. Choose the ACP mode before `execute()`. +[`decryptForTx`](/cofhe/client-sdk/guides/decrypt-to-tx) resolves to `{ ctHash, decryptedValue, signature }`. Choose the ACP mode before `execute()`. ### Public handles @@ -187,11 +187,11 @@ await counter.write.publishCount([Number(result.decryptedValue), result.signatur -`HHE1000: Artifact for contract "MockTaskManager" not found` means the mock contracts are missing from `solidity.npmFilesToBuild`. Add them as shown in [Getting Started](/client-sdk/hardhat-3-plugin/getting-started#install-the-plugin). +`HHE1000: Artifact for contract "MockTaskManager" not found` means the mock contracts are missing from `solidity.npmFilesToBuild`. Add them as shown in [Getting Started](/cofhe/client-sdk/hardhat-3-plugin/getting-started#install-the-plugin). -Error `TS2345` on `createClientWithBatteries(walletClient)` or `client.connect(...)` means two copies of viem are installed. Add the `viem` override from [Getting Started](/client-sdk/hardhat-3-plugin/getting-started#install-the-plugin) and reinstall from a clean `node_modules`. +Error `TS2345` on `createClientWithBatteries(walletClient)` or `client.connect(...)` means two copies of viem are installed. Add the `viem` override from [Getting Started](/cofhe/client-sdk/hardhat-3-plugin/getting-started#install-the-plugin) and reinstall from a clean `node_modules`. @@ -203,11 +203,11 @@ The SDK types only offer `execute()` after `setConsumingContract()`, so TypeScri -The contract did not call `FHE.allowThis` on a stored handle, so its next transaction cannot use it. viem reports the revert by its selector, `0x4d13139e`, which is `ACLNotAllowed(uint256,address)`. Wrap the call in [`withLogs`](/client-sdk/hardhat-3-plugin/logging) to see which grants each operation made. +The contract did not call `FHE.allowThis` on a stored handle, so its next transaction cannot use it. viem reports the revert by its selector, `0x4d13139e`, which is `ACLNotAllowed(uint256,address)`. Wrap the call in [`withLogs`](/cofhe/client-sdk/hardhat-3-plugin/logging) to see which grants each operation made. ## Related -- [Hardhat 2 plugin testing](/client-sdk/hardhat-plugin/testing): the same patterns with Mocha and ethers. -- [Decrypt to transact](/client-sdk/guides/decrypt-to-tx): the full `decryptForTx` guide. +- [Hardhat 2 plugin testing](/cofhe/client-sdk/hardhat-plugin/testing): the same patterns with Mocha and ethers. +- [Decrypt to transact](/cofhe/client-sdk/guides/decrypt-to-tx): the full `decryptForTx` guide. diff --git a/client-sdk/hardhat-plugin/client.mdx b/cofhe/client-sdk/hardhat-plugin/client.mdx similarity index 90% rename from client-sdk/hardhat-plugin/client.mdx rename to cofhe/client-sdk/hardhat-plugin/client.mdx index 759874d7..f498f6a6 100644 --- a/client-sdk/hardhat-plugin/client.mdx +++ b/cofhe/client-sdk/hardhat-plugin/client.mdx @@ -92,7 +92,7 @@ await cofheClient.connect(publicClient, walletClient); Once connected, the client works identically to the standard SDK client. See: -- [Encrypting Inputs](/client-sdk/guides/encrypting-inputs) -- [Decrypt to View](/client-sdk/guides/decrypt-to-view) -- [Decrypt to Transact](/client-sdk/guides/decrypt-to-tx) -- [Access Control Permissions](/client-sdk/guides/acps) +- [Encrypting Inputs](/cofhe/client-sdk/guides/encrypting-inputs) +- [Decrypt to View](/cofhe/client-sdk/guides/decrypt-to-view) +- [Decrypt to Transact](/cofhe/client-sdk/guides/decrypt-to-tx) +- [Access Control Permissions](/cofhe/client-sdk/guides/acps) diff --git a/client-sdk/hardhat-plugin/getting-started.mdx b/cofhe/client-sdk/hardhat-plugin/getting-started.mdx similarity index 86% rename from client-sdk/hardhat-plugin/getting-started.mdx rename to cofhe/client-sdk/hardhat-plugin/getting-started.mdx index e7844ff0..6e3c1a01 100644 --- a/client-sdk/hardhat-plugin/getting-started.mdx +++ b/cofhe/client-sdk/hardhat-plugin/getting-started.mdx @@ -76,7 +76,7 @@ export default { | `'v'` | Single summary line per mock (default since `0.5.0`). | | `'vv'` | Full per-contract deployment log, including each contract's deployed address. | -This is separate from **runtime** FHE-op logging, the entries printed when your tests actually call `FHE.*`. That is controlled onchain rather than from this config; see [Logging](/client-sdk/hardhat-plugin/logging). +This is separate from **runtime** FHE-op logging, the entries printed when your tests actually call `FHE.*`. That is controlled onchain rather than from this config; see [Logging](/cofhe/client-sdk/hardhat-plugin/logging). ## Pre-configured networks @@ -105,7 +105,7 @@ COFHE_SKIP_MOCKS_DEPLOY=1 npx hardhat test ## Next steps -- [Client](/client-sdk/hardhat-plugin/client): create and connect a CoFHE client in tests. -- [Mock Contracts](/client-sdk/hardhat-plugin/mock-contracts): read plaintext values and interact with mock contracts. -- [Logging](/client-sdk/hardhat-plugin/logging): inspect FHE operations in test output. -- [Testing](/client-sdk/hardhat-plugin/testing): end-to-end test patterns. +- [Client](/cofhe/client-sdk/hardhat-plugin/client): create and connect a CoFHE client in tests. +- [Mock Contracts](/cofhe/client-sdk/hardhat-plugin/mock-contracts): read plaintext values and interact with mock contracts. +- [Logging](/cofhe/client-sdk/hardhat-plugin/logging): inspect FHE operations in test output. +- [Testing](/cofhe/client-sdk/hardhat-plugin/testing): end-to-end test patterns. diff --git a/client-sdk/hardhat-plugin/logging.mdx b/cofhe/client-sdk/hardhat-plugin/logging.mdx similarity index 100% rename from client-sdk/hardhat-plugin/logging.mdx rename to cofhe/client-sdk/hardhat-plugin/logging.mdx diff --git a/client-sdk/hardhat-plugin/mock-contracts.mdx b/cofhe/client-sdk/hardhat-plugin/mock-contracts.mdx similarity index 100% rename from client-sdk/hardhat-plugin/mock-contracts.mdx rename to cofhe/client-sdk/hardhat-plugin/mock-contracts.mdx diff --git a/client-sdk/hardhat-plugin/testing.mdx b/cofhe/client-sdk/hardhat-plugin/testing.mdx similarity index 90% rename from client-sdk/hardhat-plugin/testing.mdx rename to cofhe/client-sdk/hardhat-plugin/testing.mdx index 55948501..bd76a7d0 100644 --- a/client-sdk/hardhat-plugin/testing.mdx +++ b/cofhe/client-sdk/hardhat-plugin/testing.mdx @@ -23,7 +23,7 @@ before(async () => { }); ``` -See [Client](/client-sdk/hardhat-plugin/client) for manual setup options. +See [Client](/cofhe/client-sdk/hardhat-plugin/client) for manual setup options. ## Encrypt to store to decrypt @@ -68,7 +68,7 @@ const plaintext = await hre.cofhe.mocks.getPlaintext(ctHash); await hre.cofhe.mocks.expectPlaintext(ctHash, 100n); ``` -See [Mock Contracts](/client-sdk/hardhat-plugin/mock-contracts) for details. +See [Mock Contracts](/cofhe/client-sdk/hardhat-plugin/mock-contracts) for details. ## Access Control Permissions @@ -99,7 +99,7 @@ const aliceClient = await hre.cofhe.createClientWithBatteries(alice); ## `decryptForTx` patterns -[`decryptForTx`](/client-sdk/guides/decrypt-to-tx) returns a `{ ctHash, decryptedValue, signature }` tuple for onchain submission. The ACP mode must be selected explicitly. +[`decryptForTx`](/cofhe/client-sdk/guides/decrypt-to-tx) returns a `{ ctHash, decryptedValue, signature }` tuple for onchain submission. The ACP mode must be selected explicitly. ### Globally allowed values (`.withoutACP()`) @@ -155,4 +155,4 @@ await myContract.revealValue( ); ``` -For a full walkthrough of `decryptForTx`, see [Decrypt to Transact](/client-sdk/guides/decrypt-to-tx). +For a full walkthrough of `decryptForTx`, see [Decrypt to Transact](/cofhe/client-sdk/guides/decrypt-to-tx). diff --git a/client-sdk/introduction/installation.mdx b/cofhe/client-sdk/introduction/installation.mdx similarity index 86% rename from client-sdk/introduction/installation.mdx rename to cofhe/client-sdk/introduction/installation.mdx index 6abe0303..df8bed45 100644 --- a/client-sdk/introduction/installation.mdx +++ b/cofhe/client-sdk/introduction/installation.mdx @@ -33,7 +33,7 @@ yarn add @cofhe/sdk@^0.8.0 @fhenixprotocol/cofhe-contracts@^1.0.0 | `@fhenixprotocol/cofhe-contracts` | `^1.0.0` | `FHE.sol`, the Solidity library imported by your contracts | -`@cofhe/sdk` `0.7.x` pairs with `@fhenixprotocol/cofhe-contracts` `0.2.0`. Keep every `@cofhe/*` package on the same version. They are released together and pin each other exactly. The [compatibility page](/get-started/introduction/compatibility) carries the full table. +`@cofhe/sdk` `0.7.x` pairs with `@fhenixprotocol/cofhe-contracts` `0.2.0`. Keep every `@cofhe/*` package on the same version. They are released together and pin each other exactly. The [compatibility page](/cofhe/get-started/introduction/compatibility) carries the full table. ## For Hardhat projects @@ -62,7 +62,7 @@ yarn add @cofhe/hardhat-plugin@^0.8.0 @cofhe/sdk@^0.8.0 @fhenixprotocol/cofhe-co | `@cofhe/sdk` | `^0.8.0` | Client-side encryption, decryption, and ACP management | | `@fhenixprotocol/cofhe-contracts` | `^1.0.0` | `FHE.sol`, the Solidity library imported by your contracts | -See the [Hardhat Plugin Getting Started](/client-sdk/hardhat-plugin/getting-started) guide for configuration details. +See the [Hardhat Plugin Getting Started](/cofhe/client-sdk/hardhat-plugin/getting-started) guide for configuration details. ## For Foundry projects @@ -97,7 +97,7 @@ forge install foundry-rs/forge-std The Foundry plugin uses Solidity-only abstractions, so tests need no `@cofhe/sdk` (JS). -See the [Foundry Plugin Getting Started](/client-sdk/foundry-plugin/getting-started) guide for `foundry.toml` and `remappings.txt` setup. +See the [Foundry Plugin Getting Started](/cofhe/client-sdk/foundry-plugin/getting-started) guide for `foundry.toml` and `remappings.txt` setup. ## Runtime entrypoints @@ -116,5 +116,5 @@ import { Encryptable, FheTypes } from '@cofhe/sdk'; ## Next steps -- [Quick start](/client-sdk/quick-start/javascript): write your first FHE contract and test. -- [Client setup](/client-sdk/guides/client-setup): configure and connect the SDK client. +- [Quick start](/cofhe/client-sdk/quick-start/javascript): write your first FHE contract and test. +- [Client setup](/cofhe/client-sdk/guides/client-setup): configure and connect the SDK client. diff --git a/client-sdk/introduction/mental-model-explorable.mdx b/cofhe/client-sdk/introduction/mental-model-explorable.mdx similarity index 100% rename from client-sdk/introduction/mental-model-explorable.mdx rename to cofhe/client-sdk/introduction/mental-model-explorable.mdx diff --git a/client-sdk/introduction/mental-model.mdx b/cofhe/client-sdk/introduction/mental-model.mdx similarity index 93% rename from client-sdk/introduction/mental-model.mdx rename to cofhe/client-sdk/introduction/mental-model.mdx index 8d96fe0e..34c61832 100644 --- a/client-sdk/introduction/mental-model.mdx +++ b/cofhe/client-sdk/introduction/mental-model.mdx @@ -65,7 +65,7 @@ When a user wants to read their counter value, they use one of the SDK's two dec 1. The user reads the encrypted handle (`ctHash`) from the contract 2. An ACP authorizes decryption. Created via `client.acp.getOrCreateSelfACP()` -3. The SDK asks [Teecryptor](/deep-dive/cofhe-components/teecryptor) to decrypt the handle and seal the result to the ACP's sealing key +3. The SDK asks [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) to decrypt the handle and seal the result to the ACP's sealing key 4. The plaintext is returned locally for display **For onchain use (`decryptForTx`):** @@ -92,11 +92,11 @@ This is like exchanging locks on the box: {/* Diagram source: mental-model.mmd, beside this page. Edit it first, then re-run the archify build. */} -Sequence diagram of the the counter +Sequence diagram of the the counter -Color marks the zone. Your app and the Client SDK run client side, your contract and the host chain onchain, and CoFHE offchain. Hover any component or message in the [explorable version](/client-sdk/introduction/mental-model-explorable). +Color marks the zone. Your app and the Client SDK run client side, your contract and the host chain onchain, and CoFHE offchain. Hover any component or message in the [explorable version](/cofhe/client-sdk/introduction/mental-model-explorable). ## Key takeaways diff --git a/client-sdk/introduction/mental-model.mmd b/cofhe/client-sdk/introduction/mental-model.mmd similarity index 100% rename from client-sdk/introduction/mental-model.mmd rename to cofhe/client-sdk/introduction/mental-model.mmd diff --git a/client-sdk/introduction/migrating-from-cofhejs.mdx b/cofhe/client-sdk/introduction/migrating-from-cofhejs.mdx similarity index 99% rename from client-sdk/introduction/migrating-from-cofhejs.mdx rename to cofhe/client-sdk/introduction/migrating-from-cofhejs.mdx index b95dd3f4..027d5951 100644 --- a/client-sdk/introduction/migrating-from-cofhejs.mdx +++ b/cofhe/client-sdk/introduction/migrating-from-cofhejs.mdx @@ -173,7 +173,7 @@ The `Encryptable` factory functions (`Encryptable.uint32(...)`, `Encryptable.boo `cofhejs` has a single `unseal` function. `@cofhe/sdk` splits decryption into two purpose-built methods: - **`decryptForView`**: returns the plaintext for UI display (no onchain signature). -- **`decryptForTx`**: returns the plaintext **and** a [Teecryptor](/deep-dive/cofhe-components/teecryptor) signature for onchain verification. +- **`decryptForTx`**: returns the plaintext **and** a [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) signature for onchain verification. diff --git a/client-sdk/introduction/migrating-to-0-7.mdx b/cofhe/client-sdk/introduction/migrating-to-0-7.mdx similarity index 96% rename from client-sdk/introduction/migrating-to-0-7.mdx rename to cofhe/client-sdk/introduction/migrating-to-0-7.mdx index 1cc4762f..67cb4924 100644 --- a/client-sdk/introduction/migrating-to-0-7.mdx +++ b/cofhe/client-sdk/introduction/migrating-to-0-7.mdx @@ -23,7 +23,7 @@ This is one migration across three independently versioned packages. Bumping a s `fhenix-confidential-contracts` `0.4.0` depends on an exact `@fhenixprotocol/cofhe-contracts@1.0.0`. Leaving a beta pin in place resolves two copies of `FHE.sol`, and `sharedEuint64` from one is not the same type as `sharedEuint64` from the other. The resulting errors read like nonsense, so check the pin first. -If you are coming from `cofhejs` rather than `@cofhe/sdk`, follow [migrating from cofhejs](/client-sdk/introduction/migrating-from-cofhejs) first. If you are on `0.5.x`, the Solidity work below is identical, because the `InEuintXX` structs did not change between `0.5` and `0.6`. +If you are coming from `cofhejs` rather than `@cofhe/sdk`, follow [migrating from cofhejs](/cofhe/client-sdk/introduction/migrating-from-cofhejs) first. If you are on `0.5.x`, the Solidity work below is identical, because the `InEuintXX` structs did not change between `0.5` and `0.6`. ## Let the skill do the mechanical work @@ -215,7 +215,7 @@ React hooks rename the same way. `useCofhePermits` becomes `useCofheACPs`, `useC Rename only identifiers that resolve to a `@cofhe/*` import. A blind replace of `Permit` corrupts unrelated code, and the English words `permitted` and `permitting` are not renames. `isPermittedCofheEnvironment` and `isAllowedWithPermission` keep their names. -For the full type table, the new scope model, and what the client gained, see [Access Control Permissions](/client-sdk/guides/acps). +For the full type table, the new scope model, and what the client gained, see [Access Control Permissions](/cofhe/client-sdk/guides/acps). Stored permits are dropped. They were signed with retired EIP-712 types and cannot verify against the upgraded ACL, so your users are prompted to sign again on first use. Nothing needs migrating, but it looks like data loss if you are not expecting it. @@ -268,6 +268,6 @@ Verify by exercising a round trip, not by compiling. For every bare-handle funct ## Next steps -- Check every version against the [compatibility page](/get-started/introduction/compatibility). -- Read the [Access Control Permissions guide](/client-sdk/guides/acps) for the permission model in full. -- Review [encrypting inputs](/client-sdk/guides/encrypting-inputs) for the current builder API. +- Check every version against the [compatibility page](/cofhe/get-started/introduction/compatibility). +- Read the [Access Control Permissions guide](/cofhe/client-sdk/guides/acps) for the permission model in full. +- Review [encrypting inputs](/cofhe/client-sdk/guides/encrypting-inputs) for the current builder API. diff --git a/client-sdk/introduction/overview.mdx b/cofhe/client-sdk/introduction/overview.mdx similarity index 79% rename from client-sdk/introduction/overview.mdx rename to cofhe/client-sdk/introduction/overview.mdx index 54343ccc..3e91a1a4 100644 --- a/client-sdk/introduction/overview.mdx +++ b/cofhe/client-sdk/introduction/overview.mdx @@ -3,9 +3,9 @@ title: Overview description: "Introduction to @cofhe/sdk - the TypeScript client SDK for building FHE-enabled applications on Fhenix" --- -`@cofhe/sdk` is the TypeScript client SDK for [CoFHE](/deep-dive/cofhe-components/overview). It handles the client-side work of interacting with FHE-enabled smart contracts: encrypting inputs with ZK proofs, and decrypting ciphertext handles. It also manages the EIP-712 Access Control Permissions (ACPs) that authorize those decryptions. Decryption itself happens in [Teecryptor](/deep-dive/cofhe-components/teecryptor), inside a hardware-attested TEE. +`@cofhe/sdk` is the TypeScript client SDK for [CoFHE](/cofhe/deep-dive/cofhe-components/overview). It handles the client-side work of interacting with FHE-enabled smart contracts: encrypting inputs with ZK proofs, and decrypting ciphertext handles. It also manages the EIP-712 Access Control Permissions (ACPs) that authorize those decryptions. Decryption itself happens in [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor), inside a hardware-attested TEE. -Onchain, contracts use [`FHE.sol`](/fhe-library/introduction/overview) to operate on encrypted data. Offchain, this SDK prepares the inputs and reads the outputs. +Onchain, contracts use [`FHE.sol`](/cofhe/fhe-library/introduction/overview) to operate on encrypted data. Offchain, this SDK prepares the inputs and reads the outputs. ## What the SDK does @@ -94,23 +94,23 @@ const balance = await client - + Install the SDK, write a contract, and run your first encrypt to store to decrypt test in minutes. - + Encrypt plaintext values with ZK proofs before passing them to your smart contract. - + Create and manage the EIP-712 ACPs that authorize decryption of confidential data. - + Reveal encrypted values locally for UI display using ACPs. - + Decrypt with a verifiable Teecryptor signature for onchain use. diff --git a/client-sdk/quick-start/foundry.mdx b/cofhe/client-sdk/quick-start/foundry.mdx similarity index 92% rename from client-sdk/quick-start/foundry.mdx rename to cofhe/client-sdk/quick-start/foundry.mdx index 3731ee30..c79bbe22 100644 --- a/client-sdk/quick-start/foundry.mdx +++ b/cofhe/client-sdk/quick-start/foundry.mdx @@ -158,7 +158,7 @@ Test result: ok. 1 passed; 0 failed; 0 skipped; finished in … ## Next steps -- [Foundry Plugin to Getting Started](/client-sdk/foundry-plugin/getting-started): full plugin configuration and features. -- [CofheTest](/client-sdk/foundry-plugin/cofhe-test): `deployMocks`, `expectPlaintext`, log toggles. -- [CofheClient](/client-sdk/foundry-plugin/cofhe-client): encrypt inputs, decrypt for view or tx, and ACPs. -- [Testing](/client-sdk/foundry-plugin/testing): canonical test patterns for ACL, public-decrypt, and fuzzing. +- [Foundry Plugin to Getting Started](/cofhe/client-sdk/foundry-plugin/getting-started): full plugin configuration and features. +- [CofheTest](/cofhe/client-sdk/foundry-plugin/cofhe-test): `deployMocks`, `expectPlaintext`, log toggles. +- [CofheClient](/cofhe/client-sdk/foundry-plugin/cofhe-client): encrypt inputs, decrypt for view or tx, and ACPs. +- [Testing](/cofhe/client-sdk/foundry-plugin/testing): canonical test patterns for ACL, public-decrypt, and fuzzing. diff --git a/client-sdk/quick-start/hardhat.mdx b/cofhe/client-sdk/quick-start/hardhat.mdx similarity index 93% rename from client-sdk/quick-start/hardhat.mdx rename to cofhe/client-sdk/quick-start/hardhat.mdx index da7d2046..fe60431e 100644 --- a/client-sdk/quick-start/hardhat.mdx +++ b/cofhe/client-sdk/quick-start/hardhat.mdx @@ -151,6 +151,6 @@ The plugin deploys mock contracts automatically, no extra setup needed. ## Next steps -- [Hardhat Plugin](/client-sdk/hardhat-plugin/getting-started): full plugin configuration and features. -- [Mock Contracts](/client-sdk/hardhat-plugin/mock-contracts): read plaintext directly and assert encrypted state in tests. -- [Logging](/client-sdk/hardhat-plugin/logging): inspect every FHE operation your contracts perform. +- [Hardhat Plugin](/cofhe/client-sdk/hardhat-plugin/getting-started): full plugin configuration and features. +- [Mock Contracts](/cofhe/client-sdk/hardhat-plugin/mock-contracts): read plaintext directly and assert encrypted state in tests. +- [Logging](/cofhe/client-sdk/hardhat-plugin/logging): inspect every FHE operation your contracts perform. diff --git a/client-sdk/quick-start/javascript.mdx b/cofhe/client-sdk/quick-start/javascript.mdx similarity index 81% rename from client-sdk/quick-start/javascript.mdx rename to cofhe/client-sdk/quick-start/javascript.mdx index c3179e22..fe772b4a 100644 --- a/client-sdk/quick-start/javascript.mdx +++ b/cofhe/client-sdk/quick-start/javascript.mdx @@ -93,7 +93,7 @@ await client.connect(publicClient, walletClient); -If you use Ethers.js instead of viem, see the [Client Setup](/client-sdk/guides/client-setup) guide for adapter usage. +If you use Ethers.js instead of viem, see the [Client Setup](/cofhe/client-sdk/guides/client-setup) guide for adapter usage. ## 3. Encrypt and send @@ -132,8 +132,8 @@ console.log(plaintext); // 42n ## Next steps -- [Client Setup](/client-sdk/guides/client-setup): adapters, connection management, and config options. -- [Encrypting Inputs](/client-sdk/guides/encrypting-inputs): supported types, builder API, and progress callbacks. -- [Access Control Permissions](/client-sdk/guides/acps): create, share, and manage decryption authorization. -- [Decrypt to View](/client-sdk/guides/decrypt-to-view): reveal encrypted state in your UI. -- [Decrypt to Transact](/client-sdk/guides/decrypt-to-tx): decrypt with a verifiable signature for onchain use. +- [Client Setup](/cofhe/client-sdk/guides/client-setup): adapters, connection management, and config options. +- [Encrypting Inputs](/cofhe/client-sdk/guides/encrypting-inputs): supported types, builder API, and progress callbacks. +- [Access Control Permissions](/cofhe/client-sdk/guides/acps): create, share, and manage decryption authorization. +- [Decrypt to View](/cofhe/client-sdk/guides/decrypt-to-view): reveal encrypted state in your UI. +- [Decrypt to Transact](/cofhe/client-sdk/guides/decrypt-to-tx): decrypt with a verifiable signature for onchain use. diff --git a/client-sdk/quick-start/react.mdx b/cofhe/client-sdk/quick-start/react.mdx similarity index 69% rename from client-sdk/quick-start/react.mdx rename to cofhe/client-sdk/quick-start/react.mdx index e8b52e95..044a0268 100644 --- a/client-sdk/quick-start/react.mdx +++ b/cofhe/client-sdk/quick-start/react.mdx @@ -7,4 +7,4 @@ description: "Get started with @cofhe/sdk in a React application" `@cofhe/react` is currently in development. This page will be updated with a full quick start guide once the React library is available. -In the meantime, you can use `@cofhe/sdk/web` directly in your React app. See the [Client Setup](/client-sdk/guides/client-setup) guide for how to configure and connect the SDK with viem or wagmi. +In the meantime, you can use `@cofhe/sdk/web` directly in your React app. See the [Client Setup](/cofhe/client-sdk/guides/client-setup) guide for how to configure and connect the SDK with viem or wagmi. diff --git a/client-sdk/reference/foundry-reference.mdx b/cofhe/client-sdk/reference/foundry-reference.mdx similarity index 94% rename from client-sdk/reference/foundry-reference.mdx rename to cofhe/client-sdk/reference/foundry-reference.mdx index 96ddfd56..8e3e3866 100644 --- a/client-sdk/reference/foundry-reference.mdx +++ b/cofhe/client-sdk/reference/foundry-reference.mdx @@ -4,7 +4,7 @@ description: "Complete API reference for @cofhe/foundry-plugin" --- -This page summarizes the public surface of `@cofhe/foundry-plugin`. For task-oriented walkthroughs, see [Getting Started](/client-sdk/foundry-plugin/getting-started) and [Testing](/client-sdk/foundry-plugin/testing). +This page summarizes the public surface of `@cofhe/foundry-plugin`. For task-oriented walkthroughs, see [Getting Started](/cofhe/client-sdk/foundry-plugin/getting-started) and [Testing](/cofhe/client-sdk/foundry-plugin/testing). ## `CofheTest` @@ -90,7 +90,7 @@ All produce signed `EncryptedInput` shapes signed for `account()`. ### ACPs -Access Control Permission (ACP) helpers. See [Access Control Permissions](/client-sdk/guides/acps). +Access Control Permission (ACP) helpers. See [Access Control Permissions](/cofhe/client-sdk/guides/acps). | Function | Description | | --- | --- | @@ -142,4 +142,4 @@ hardhat/=node_modules/forge-std/src/ | `@cofhe/mock-contracts` | `0.8.0` | | `@fhenixprotocol/cofhe-contracts` | `1.0.0` | -See the [Compatibility](/get-started/introduction/compatibility) page for the canonical table. +See the [Compatibility](/cofhe/get-started/introduction/compatibility) page for the canonical table. diff --git a/client-sdk/reference/hardhat-reference.mdx b/cofhe/client-sdk/reference/hardhat-reference.mdx similarity index 100% rename from client-sdk/reference/hardhat-reference.mdx rename to cofhe/client-sdk/reference/hardhat-reference.mdx diff --git a/client-sdk/reference/sdk-reference.mdx b/cofhe/client-sdk/reference/sdk-reference.mdx similarity index 100% rename from client-sdk/reference/sdk-reference.mdx rename to cofhe/client-sdk/reference/sdk-reference.mdx diff --git a/deep-dive/cofhe-components/acl.mdx b/cofhe/deep-dive/cofhe-components/acl.mdx similarity index 78% rename from deep-dive/cofhe-components/acl.mdx rename to cofhe/deep-dive/cofhe-components/acl.mdx index 48cead48..3181a1ec 100644 --- a/deep-dive/cofhe-components/acl.mdx +++ b/cofhe/deep-dive/cofhe-components/acl.mdx @@ -7,9 +7,9 @@ description: "Onchain contract that manages and enforces access control for ciph |--------|-------------| | **Type** | Contract deployed on every host chain, UUPS-upgradeable behind a proxy. | | **Function** | Manages and enforces access control for ciphertexts, for both contracts and user accounts. | -| **Responsibilities** | • Records who may use each handle in FHE operations.
• Records which handles may be decrypted, and by whom.
• Answers the access queries of the [TaskManager](/deep-dive/cofhe-components/task-manager) and the decryption component. | +| **Responsibilities** | • Records who may use each handle in FHE operations.
• Records which handles may be decrypted, and by whom.
• Answers the access queries of the [TaskManager](/cofhe/deep-dive/cofhe-components/task-manager) and the decryption component. | -Every encrypted value in CoFHE is guarded by this contract. A handle is useless to anyone the ACL does not list. The TaskManager rejects operations on inputs the caller cannot access, and [Teecryptor](/deep-dive/cofhe-components/teecryptor) refuses to decrypt handles without a matching grant. +Every encrypted value in CoFHE is guarded by this contract. A handle is useless to anyone the ACL does not list. The TaskManager rejects operations on inputs the caller cannot access, and [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) refuses to decrypt handles without a matching grant. ## Grant tiers @@ -20,7 +20,7 @@ Every encrypted value in CoFHE is guarded by this contract. A handle is useless | **Global** | `FHE.allowGlobal` (alias `FHE.allowPublic`) | Every account. Also marks the handle publicly decryptable. | | **Decryption** | `TaskManager.allowForDecryption` | Adds the handle to the decryption allowlist and emits `AllowedForDecryption`. | -Every tier above requires the requester to hold access to the handle already. Only the transient tier expires, and the ACL has no revoke. So any holder can extend access to anyone. See [who you trust when you grant access](/fhe-library/core-concepts/access-control#who-you-trust-when-you-grant-access). +Every tier above requires the requester to hold access to the handle already. Only the transient tier expires, and the ACL has no revoke. So any holder can extend access to anyone. See [who you trust when you grant access](/cofhe/fhe-library/core-concepts/access-control#who-you-trust-when-you-grant-access). ## Writes go through the TaskManager @@ -28,7 +28,7 @@ All state-mutating entry points require `msg.sender` to be the TaskManager; dire ## ACPs -Offchain reads are authorized by an [ACP](/client-sdk/guides/acps), an Access Control Permission: an EIP-712 body signed by its issuer. Beyond the issuer, expiration, and the sealing key used for sealed outputs, an ACP carries a **scope**: global, limited to specific contracts, or limited to specific handles. A scope only narrows what the issuer could already access; it never grants more. +Offchain reads are authorized by an [ACP](/cofhe/client-sdk/guides/acps), an Access Control Permission: an EIP-712 body signed by its issuer. Beyond the issuer, expiration, and the sealing key used for sealed outputs, an ACP carries a **scope**: global, limited to specific contracts, or limited to specific handles. A scope only narrows what the issuer could already access; it never grants more. An ACP can be shared with a recipient, revoked through a revoker contract, and handed over onchain through the ACP share registry. @@ -43,7 +43,7 @@ An ACP can be shared with a recipient, revoked through a revoker contract, and h | `isAllowedForDecryption(handle)` | Is the handle on the decryption allowlist? | | isAllowedWithPermission | Does this ACP authorize its issuer for the given handle? | -The last two are what the decryption path runs on. For every `decrypt` or `sealoutput` request, Teecryptor queries the ACL through the TaskManager: `isAllowedWithPermission` when an ACP is attached, or `isPubliclyAllowed` (the TaskManager's wrapper over `globalAllowed`) when none is. A future [Threshold Network](/deep-dive/research/future-plans) will consume the same interface. +The last two are what the decryption path runs on. For every `decrypt` or `sealoutput` request, Teecryptor queries the ACL through the TaskManager: `isAllowedWithPermission` when an ACP is attached, or `isPubliclyAllowed` (the TaskManager's wrapper over `globalAllowed`) when none is. A future [Threshold Network](/cofhe/deep-dive/research/future-plans) will consume the same interface. ## Upgrades diff --git a/deep-dive/cofhe-components/commitment-registry-explorable.mdx b/cofhe/deep-dive/cofhe-components/commitment-registry-explorable.mdx similarity index 100% rename from deep-dive/cofhe-components/commitment-registry-explorable.mdx rename to cofhe/deep-dive/cofhe-components/commitment-registry-explorable.mdx diff --git a/deep-dive/cofhe-components/commitment-registry.mdx b/cofhe/deep-dive/cofhe-components/commitment-registry.mdx similarity index 84% rename from deep-dive/cofhe-components/commitment-registry.mdx rename to cofhe/deep-dive/cofhe-components/commitment-registry.mdx index 0f2fb992..f0539186 100644 --- a/deep-dive/cofhe-components/commitment-registry.mdx +++ b/cofhe/deep-dive/cofhe-components/commitment-registry.mdx @@ -7,12 +7,12 @@ description: "Registry-chain contract that records FHE computation commitments. |--------|-------------| | **Type** | UUPS-upgradeable Solidity contract deployed on a dedicated **registry chain**. | | **Function** | Records `(version, handle) → commitHash` entries for every ciphertext the coprocessor produces or verifies, computed results and encrypted inputs alike. | -| **Responsibilities** | • Provide an authoritative source of ciphertext integrity that [Teecryptor](/deep-dive/cofhe-components/teecryptor) checks **before** decrypting.
• Group commitments by an opaque `version` tag so a future tfhe-rs / FHE-parameter upgrade can roll out without invalidating earlier ciphertexts.
• Enforce write-once semantics per `(version, handle)` to prevent commitment replacement.
• Expose paginated enumeration so offchain tooling can audit what has been posted. | +| **Responsibilities** | • Provide an authoritative source of ciphertext integrity that [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) checks **before** decrypting.
• Group commitments by an opaque `version` tag so a future tfhe-rs / FHE-parameter upgrade can roll out without invalidating earlier ciphertexts.
• Enforce write-once semantics per `(version, handle)` to prevent commitment replacement.
• Expose paginated enumeration so offchain tooling can audit what has been posted. | | **Deployment** | One deployment per registry chain, behind an ERC-1967 proxy. The production registry is `0x4B82F827C03fad5739EFEcfcF743E65E732be695` on Arbitrum One, and it serves every host chain. | ## What a commitment is -A commitment is the `keccak256` hash of a ciphertext's canonical stored bytes. The [compute pipeline](/deep-dive/cofhe-components/compute-pipeline) produces one for every result it computes, and anchors one for every encrypted input the [ZK Verifier](/deep-dive/cofhe-components/zk-verifier) approves. It batches them and writes them to this registry. +A commitment is the `keccak256` hash of a ciphertext's canonical stored bytes. The [compute pipeline](/cofhe/deep-dive/cofhe-components/compute-pipeline) produces one for every result it computes, and anchors one for every encrypted input the [ZK Verifier](/cofhe/deep-dive/cofhe-components/zk-verifier) approves. It batches them and writes them to this registry. ## Who writes and who reads @@ -20,16 +20,16 @@ One component writes commitments, and one component reads them. The write happen {/* Diagram source: commitment-registry.mmd, beside this page. Edit it first, then re-run the archify build. */} -Sequence diagram of the commitment write and read +Sequence diagram of the commitment write and read -The compute pipeline and Teecryptor run offchain inside CoFHE; the registry itself is onchain. Hover any component or message in the [explorable version](/deep-dive/cofhe-components/commitment-registry-explorable). +The compute pipeline and Teecryptor run offchain inside CoFHE; the registry itself is onchain. Hover any component or message in the [explorable version](/cofhe/deep-dive/cofhe-components/commitment-registry-explorable). ## Why commitments? -The commitment is a safety check in the decryption flow. Before decrypting anything, [Teecryptor](/deep-dive/cofhe-components/teecryptor) confirms that the ciphertext bytes it fetched hash to the commitment anchored onchain. It only ever decrypts a ciphertext the coprocessor actually produced, never a tampered or substituted one. +The commitment is a safety check in the decryption flow. Before decrypting anything, [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) confirms that the ciphertext bytes it fetched hash to the commitment anchored onchain. It only ever decrypts a ciphertext the coprocessor actually produced, never a tampered or substituted one. The registry also makes the coprocessor accountable. Every result it has ever produced is committed publicly, permanently, and write-once, so its computation history is tamper-evident and open to independent audit. Commitments for every host chain land on one dedicated **registry chain**, which gives the decryption path a single place to verify against. @@ -49,7 +49,7 @@ mapping(address => bool) poster `version` is an opaque `bytes32` tag chosen by the coprocessor when FHE parameters change. The current tag is the number 2 encoded as `bytes32`. Every version moves through a small state machine: -State machine for a commitment version: Unset to Active to Deprecated, with Revoked as the terminal state +State machine for a commitment version: Unset to Active to Deprecated, with Revoked as the terminal state diff --git a/deep-dive/cofhe-components/commitment-registry.mmd b/cofhe/deep-dive/cofhe-components/commitment-registry.mmd similarity index 100% rename from deep-dive/cofhe-components/commitment-registry.mmd rename to cofhe/deep-dive/cofhe-components/commitment-registry.mmd diff --git a/deep-dive/cofhe-components/commitment-version.mmd b/cofhe/deep-dive/cofhe-components/commitment-version.mmd similarity index 100% rename from deep-dive/cofhe-components/commitment-version.mmd rename to cofhe/deep-dive/cofhe-components/commitment-version.mmd diff --git a/deep-dive/cofhe-components/compute-pipeline.mdx b/cofhe/deep-dive/cofhe-components/compute-pipeline.mdx similarity index 83% rename from deep-dive/cofhe-components/compute-pipeline.mdx rename to cofhe/deep-dive/cofhe-components/compute-pipeline.mdx index 969bc161..4ac8e675 100644 --- a/deep-dive/cofhe-components/compute-pipeline.mdx +++ b/cofhe/deep-dive/cofhe-components/compute-pipeline.mdx @@ -14,7 +14,7 @@ The compute pipeline is the computation side of CoFHE. Contracts never call it. Four components make up the pipeline. Each one owns a single step, and work moves in one direction. -The compute pipeline: TaskManager feeds the slim listener, FheOS, the FHE Engine and the blockchain poster, which posts commitments to the registry chain +The compute pipeline: TaskManager feeds the slim listener, FheOS, the FHE Engine and the blockchain poster, which posts commitments to the registry chain @@ -43,10 +43,10 @@ Note the name. The FHE Engine is one component inside the compute pipeline, not ## Blockchain poster -For every stored result, the pipeline produces a commitment, the `keccak256` hash of the stored ciphertext bytes. The blockchain poster batches those commitments and posts them to the [CommitmentRegistry](/deep-dive/cofhe-components/commitment-registry) on the registry chain. +For every stored result, the pipeline produces a commitment, the `keccak256` hash of the stored ciphertext bytes. The blockchain poster batches those commitments and posts them to the [CommitmentRegistry](/cofhe/deep-dive/cofhe-components/commitment-registry) on the registry chain. -This is the anchor [Teecryptor](/deep-dive/cofhe-components/teecryptor) verifies before decrypting anything. Only bytes that hash to a registered commitment ever reach the decryption key. +This is the anchor [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) verifies before decrypting anything. Only bytes that hash to a registered commitment ever reach the decryption key. ## Key material -The pipeline computes with the FHE public key material only. Production builds load no decryption key, so a compromised pipeline can corrupt results (which commitment verification would catch) but cannot read them. Decryption capability exists solely inside [Teecryptor](/deep-dive/cofhe-components/teecryptor)'s attested enclave. +The pipeline computes with the FHE public key material only. Production builds load no decryption key, so a compromised pipeline can corrupt results (which commitment verification would catch) but cannot read them. Decryption capability exists solely inside [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor)'s attested enclave. diff --git a/deep-dive/cofhe-components/compute-pipeline.mmd b/cofhe/deep-dive/cofhe-components/compute-pipeline.mmd similarity index 100% rename from deep-dive/cofhe-components/compute-pipeline.mmd rename to cofhe/deep-dive/cofhe-components/compute-pipeline.mmd diff --git a/deep-dive/cofhe-components/key-management-explorable.mdx b/cofhe/deep-dive/cofhe-components/key-management-explorable.mdx similarity index 100% rename from deep-dive/cofhe-components/key-management-explorable.mdx rename to cofhe/deep-dive/cofhe-components/key-management-explorable.mdx diff --git a/deep-dive/cofhe-components/key-management.mdx b/cofhe/deep-dive/cofhe-components/key-management.mdx similarity index 88% rename from deep-dive/cofhe-components/key-management.mdx rename to cofhe/deep-dive/cofhe-components/key-management.mdx index 5dc976f3..2a9c43fa 100644 --- a/deep-dive/cofhe-components/key-management.mdx +++ b/cofhe/deep-dive/cofhe-components/key-management.mdx @@ -7,9 +7,9 @@ CoFHE's security rests on a small set of keys, and none of them is ever held who | Key | Used by | Purpose | |-----|---------|---------| -| FHE network key | [Teecryptor](/deep-dive/cofhe-components/teecryptor) | Decrypts ciphertexts inside the enclave | +| FHE network key | [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) | Decrypts ciphertexts inside the enclave | | Result-signing key | Teecryptor | Signs decrypt results the TaskManager verifies onchain | -| Verifier signing key | [ZK Verifier](/deep-dive/cofhe-components/zk-verifier) | Signs verified input batches | +| Verifier signing key | [ZK Verifier](/cofhe/deep-dive/cofhe-components/zk-verifier) | Signs verified input batches | | Public material | Everyone | The network public key and CRS that clients encrypt against | ## The ceremony @@ -20,11 +20,11 @@ Each share goes to one **partner**: an independent custodian with its own share {/* Diagram source: key-management.mmd, beside this page. Edit it first, then re-run the archify build. */} -Sequence diagram of the key management +Sequence diagram of the key management -Color marks the zone. The keygen ceremony and the component enclave (Teecryptor or the ZK Verifier) run inside CoFHE. The partners are independent custodians, so they are not colored as CoFHE's. Hover any component or message in the [explorable version](/deep-dive/cofhe-components/key-management-explorable). +Color marks the zone. The keygen ceremony and the component enclave (Teecryptor or the ZK Verifier) run inside CoFHE. The partners are independent custodians, so they are not colored as CoFHE's. Hover any component or message in the [explorable version](/cofhe/deep-dive/cofhe-components/key-management-explorable). ## Custody diff --git a/deep-dive/cofhe-components/key-management.mmd b/cofhe/deep-dive/cofhe-components/key-management.mmd similarity index 100% rename from deep-dive/cofhe-components/key-management.mmd rename to cofhe/deep-dive/cofhe-components/key-management.mmd diff --git a/cofhe/deep-dive/cofhe-components/overview.mdx b/cofhe/deep-dive/cofhe-components/overview.mdx new file mode 100644 index 00000000..62ae6653 --- /dev/null +++ b/cofhe/deep-dive/cofhe-components/overview.mdx @@ -0,0 +1,43 @@ +--- +title: "CoFHE Architecture Overview" +description: "How CoFHE's onchain contracts and offchain components fit together to run FHE computations for any EVM chain" +--- + +CoFHE (Coprocessor for Fully Homomorphic Encryption) lets smart contracts compute on encrypted data. Contracts request operations through onchain calls; a set of offchain components executes them and commits to the results. Data stays encrypted until an authorized decryption, and every result can be verified against an onchain commitment. + +{/* Diagram source: overview.mmd, beside this page. Edit it first, then re-run the archify build. */} + +CoFHE architecture: the Client SDK above your contracts on the host chain, the independent partners above CoFHE offchain with the ZK Verifier, Teecryptor, the ciphertext store and the compute pipeline, and the CommitmentRegistry on the registry chain to the right + + + +Color marks the zone, and the boxes group what runs where. Each component is described under [the onchain contracts](#the-onchain-contracts) and [the offchain components](#the-offchain-components) below. + + +## The onchain contracts + +- **FHE.sol**: the Solidity library your contract imports. It exposes arithmetic, comparison, and logical operations on encrypted values, plus access control (`allow`, `allowGlobal`) and decrypt-result verification. +- **CoFHEAddressBook**: deployed at `0xC0F4e00E531a2B086492Ae3DCC1515038307196b` on every supported chain, mainnet and testnet. It maps a TaskManager id to that chain's TaskManager, and `FHE.sol` finds the TaskManager through it with id `1`. +- **[TaskManager](/cofhe/deep-dive/cofhe-components/task-manager)**: the gateway for all FHE operation requests. It validates requests, emits task events for the offchain components, and manages permissions through the ACL. +- **[ACL](/cofhe/deep-dive/cofhe-components/acl)**: the access control contract. It records who may use or decrypt each handle; all writes to it go through the TaskManager. +- **[PlaintextsStorage](/cofhe/deep-dive/cofhe-components/plaintext-storage)**: stores decrypted results. The TaskManager writes them during `publishDecryptResult`, only after ECDSA-verifying the result against `decryptResultSigner`. +- **[CommitmentRegistry](/cofhe/deep-dive/cofhe-components/commitment-registry)**: lives on a dedicated registry chain and records a hash commitment for every ciphertext the coprocessor produces or verifies. Teecryptor verifies integrity against it before decrypting anything. + +## The offchain components + +- **[Client SDK](/cofhe/client-sdk/introduction/overview)** (`@cofhe/sdk`): the TypeScript library applications use to encrypt inputs, manage [Access Control Permissions](/cofhe/client-sdk/guides/acps) (ACPs), and decrypt outputs. +- **[ZK Verifier](/cofhe/deep-dive/cofhe-components/zk-verifier)**: verifies encrypted inputs in batches, inside a hardware-attested TEE. It checks each zero-knowledge proof, stores the ciphertexts, and signs one approval for the whole batch. +- **[Compute pipeline](/cofhe/deep-dive/cofhe-components/compute-pipeline)**: the execution pipeline. It subscribes to TaskManager events, validates and orders operations, runs them on encrypted data, and posts a commitment for every result. +- **Ciphertext store**: the database that holds every ciphertext, fronted by the CT Server. The ZK Verifier writes verified inputs, the FHE Engine reads operands and writes results, and Teecryptor fetches bytes to decrypt. +- **[Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor)**: the decryption component. It runs inside a hardware-attested TEE, authorizes every request against the onchain ACL, verifies the ciphertext commitment, and returns signed or sealed results. +- **Partners**: independent custodians of the key material. Each holds a Shamir share and releases it only to an attested enclave. See [Key Management](/cofhe/deep-dive/cofhe-components/key-management). + +## Data flows + +1. **[Encryption request](/cofhe/deep-dive/data-flows/encryption-request-flow)**: an input is encrypted client-side and proven valid with a zero-knowledge proof before it enters the chain. +2. **[FHE operation](/cofhe/deep-dive/data-flows/fhe-operation-request-flow)**: a contract requests a computation; the coprocessor executes it and commits to the result. +3. **[Decryption](/cofhe/deep-dive/data-flows/decryption-request-flow)**: the SDK asks Teecryptor to decrypt a handle, either as a signed plaintext for onchain publication or sealed to an ACP for offchain reads. + +## Future plans + +Two components run inside hardware-attested TEEs today: Teecryptor, which decrypts, and the ZK Verifier, which checks input proofs. Both move to multi-party computation in one planned step. See [Future Plans](/cofhe/deep-dive/research/future-plans). diff --git a/deep-dive/cofhe-components/overview.mmd b/cofhe/deep-dive/cofhe-components/overview.mmd similarity index 100% rename from deep-dive/cofhe-components/overview.mmd rename to cofhe/deep-dive/cofhe-components/overview.mmd diff --git a/deep-dive/cofhe-components/plaintext-storage.mdx b/cofhe/deep-dive/cofhe-components/plaintext-storage.mdx similarity index 74% rename from deep-dive/cofhe-components/plaintext-storage.mdx rename to cofhe/deep-dive/cofhe-components/plaintext-storage.mdx index 05e16886..8b62402a 100644 --- a/deep-dive/cofhe-components/plaintext-storage.mdx +++ b/cofhe/deep-dive/cofhe-components/plaintext-storage.mdx @@ -9,6 +9,6 @@ description: "Host-chain contract that stores published decryption results so co | **Function** | Stores published decryption results for synchronous reads. | | **Responsibilities** | • Holds the plaintext result for every published decryption
• Serves reads through the TaskManager's result getters | -Decryption happens offchain, but contracts need the result onchain. When a signed decrypt result is published through `FHE.publishDecryptResult`, the [TaskManager](/deep-dive/cofhe-components/task-manager) verifies the signature and writes the plaintext here. Only the TaskManager can write to this contract. +Decryption happens offchain, but contracts need the result onchain. When a signed decrypt result is published through `FHE.publishDecryptResult`, the [TaskManager](/cofhe/deep-dive/cofhe-components/task-manager) verifies the signature and writes the plaintext here. Only the TaskManager can write to this contract. -Contracts read results back with `FHE.getDecryptResult(handle)`, which reverts if the result is not yet published, or `FHE.getDecryptResultSafe(handle)`, which returns a ready flag instead. See the [Decryption Flow](/deep-dive/data-flows/decryption-request-flow) for the full path. +Contracts read results back with `FHE.getDecryptResult(handle)`, which reverts if the result is not yet published, or `FHE.getDecryptResultSafe(handle)`, which returns a ready flag instead. See the [Decryption Flow](/cofhe/deep-dive/data-flows/decryption-request-flow) for the full path. diff --git a/deep-dive/cofhe-components/task-manager.mdx b/cofhe/deep-dive/cofhe-components/task-manager.mdx similarity index 86% rename from deep-dive/cofhe-components/task-manager.mdx rename to cofhe/deep-dive/cofhe-components/task-manager.mdx index d754c1ec..3de21ba6 100644 --- a/deep-dive/cofhe-components/task-manager.mdx +++ b/cofhe/deep-dive/cofhe-components/task-manager.mdx @@ -18,13 +18,13 @@ The TaskManager holds two distinct signer addresses, one per trust boundary: | Signer | Verifies | |--------|----------| | verifierSigner | Encrypted inputs: the ZK Verifier signs each verified batch, and `batchVerifyInputs` checks that signature before emitting `InputVerified(ctHash, commitment)` per input. The signature binds the consuming contract, so a batch cannot be replayed elsewhere. | -| decryptResultSigner | Decrypt results: [Teecryptor](/deep-dive/cofhe-components/teecryptor) signs each plaintext it returns, and the publish path checks that signature before storing the result. | +| decryptResultSigner | Decrypt results: [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) signs each plaintext it returns, and the publish path checks that signature before storing the result. | ## Decrypt result signature verification -The TaskManager supports **permissionless publishing of decrypt results**. Anyone holding a valid signature from the decryption component can publish the result onchain. Today that signature comes from Teecryptor; a decentralized [Threshold Network](/deep-dive/research/future-plans) is the planned successor. +The TaskManager supports **permissionless publishing of decrypt results**. Anyone holding a valid signature from the decryption component can publish the result onchain. Today that signature comes from Teecryptor; a decentralized [Threshold Network](/cofhe/deep-dive/research/future-plans) is the planned successor. -Verified results are stored in the [PlaintextsStorage](/deep-dive/cofhe-components/plaintext-storage) contract, where any contract can read them back with `getDecryptResult` (reverts with `DecryptionResultNotReady` if pending) or `getDecryptResultSafe` (returns a ready flag). +Verified results are stored in the [PlaintextsStorage](/cofhe/deep-dive/cofhe-components/plaintext-storage) contract, where any contract can read them back with `getDecryptResult` (reverts with `DecryptionResultNotReady` if pending) or `getDecryptResultSafe` (returns a ready flag). ### Functions diff --git a/deep-dive/cofhe-components/teecryptor-explorable.mdx b/cofhe/deep-dive/cofhe-components/teecryptor-explorable.mdx similarity index 100% rename from deep-dive/cofhe-components/teecryptor-explorable.mdx rename to cofhe/deep-dive/cofhe-components/teecryptor-explorable.mdx diff --git a/deep-dive/cofhe-components/teecryptor.mdx b/cofhe/deep-dive/cofhe-components/teecryptor.mdx similarity index 78% rename from deep-dive/cofhe-components/teecryptor.mdx rename to cofhe/deep-dive/cofhe-components/teecryptor.mdx index 6e2d5654..e3d16068 100644 --- a/deep-dive/cofhe-components/teecryptor.mdx +++ b/cofhe/deep-dive/cofhe-components/teecryptor.mdx @@ -6,23 +6,23 @@ description: "Offchain decryption component that decrypts CoFHE ciphertexts insi | Aspect | Description | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Type** | Offchain component running inside a hardware-attested Trusted Execution Environment (TEE). | -| **Function** | Process decryption requests from the [Client SDK](/client-sdk/introduction/overview). | +| **Function** | Process decryption requests from the [Client SDK](/cofhe/client-sdk/introduction/overview). | | **Responsibilities** | • Authorizes each request against the onchain ACL
• Verifies the ciphertext against its onchain commitment
• Decrypts inside the enclave
• Signs (or seals) the result for delivery | -Teecryptor is the component that decrypts CoFHE ciphertexts. It holds the FHE secret key, but only inside a TEE: an isolated, hardware-encrypted execution environment (Intel TDX) whose exact code image is proven by remote attestation. The trust model is deliberate and worth stating plainly. Instead of splitting the decryption computation across independent parties, Teecryptor relies on hardware attestation to guarantee that only one specific, reviewable program can ever touch the key. A [Threshold Network](/deep-dive/research/future-plans) that decrypts through multi-party computation is the planned next step and will eventually replace Teecryptor. +Teecryptor is the component that decrypts CoFHE ciphertexts. It holds the FHE secret key, but only inside a TEE: an isolated, hardware-encrypted execution environment (Intel TDX) whose exact code image is proven by remote attestation. The trust model is deliberate and worth stating plainly. Instead of splitting the decryption computation across independent parties, Teecryptor relies on hardware attestation to guarantee that only one specific, reviewable program can ever touch the key. A [Threshold Network](/cofhe/deep-dive/research/future-plans) that decrypts through multi-party computation is the planned next step and will eventually replace Teecryptor. ## How a decrypt request is processed -Every `decrypt` and `sealoutput` request carries a ciphertext handle, a host chain id, and optionally an [ACP](/client-sdk/guides/acps) (Access Control Permission), sent on the wire as `acp`. A `sealoutput` request requires one, since the ACP carries the sealing key. Teecryptor then runs a fixed pipeline: +Every `decrypt` and `sealoutput` request carries a ciphertext handle, a host chain id, and optionally an [ACP](/cofhe/client-sdk/guides/acps) (Access Control Permission), sent on the wire as `acp`. A `sealoutput` request requires one, since the ACP carries the sealing key. Teecryptor then runs a fixed pipeline: -Teecryptor checks the handle against the onchain ACL through the [TaskManager](/deep-dive/cofhe-components/task-manager) on the requested host chain. With an ACP, the contract verifies its EIP-712 signature and calls `isAllowedWithPermission`. Without one, the handle must have been marked publicly decryptable, checked via `isPubliclyAllowed`. Both paths fail closed: no onchain allowance, no decryption. +Teecryptor checks the handle against the onchain ACL through the [TaskManager](/cofhe/deep-dive/cofhe-components/task-manager) on the requested host chain. With an ACP, the contract verifies its EIP-712 signature and calls `isAllowedWithPermission`. Without one, the handle must have been marked publicly decryptable, checked via `isPubliclyAllowed`. Both paths fail closed: no onchain allowance, no decryption. -Concurrently with authorization, Teecryptor confirms that the [compute pipeline](/deep-dive/cofhe-components/compute-pipeline) posted a commitment for this handle in the [CommitmentRegistry](/deep-dive/cofhe-components/commitment-registry). Commitments are write-once, so a verified result is cached permanently. +Concurrently with authorization, Teecryptor confirms that the [compute pipeline](/cofhe/deep-dive/cofhe-components/compute-pipeline) posted a commitment for this handle in the [CommitmentRegistry](/cofhe/deep-dive/cofhe-components/commitment-registry). Commitments are write-once, so a verified result is cached permanently. @@ -45,11 +45,11 @@ A handle whose ciphertext or commitment has not landed yet is not an error. Teec {/* Diagram source: teecryptor.mmd, beside this page. Edit it first, then re-run the archify build. */} -Sequence diagram of the teecryptor pipeline +Sequence diagram of the teecryptor pipeline -The Client SDK runs client side, the TaskManager and CommitmentRegistry onchain, and Teecryptor offchain inside CoFHE. Hover any component or message in the [explorable version](/deep-dive/cofhe-components/teecryptor-explorable). +The Client SDK runs client side, the TaskManager and CommitmentRegistry onchain, and Teecryptor offchain inside CoFHE. Hover any component or message in the [explorable version](/cofhe/deep-dive/cofhe-components/teecryptor-explorable). ## Attestation @@ -58,7 +58,7 @@ Remote attestation is what turns "trust the operator" into "verify the code". Be ## Key custody -The FHE secret key is never stored whole. It is split with Shamir secret sharing into six shares held by independent parties, with any three required for reconstruction (3-of-6). At boot, the attested enclave collects shares from the custodians, reconstructs the key in memory, and zeroizes the transient share material. The reconstructed key exists only inside the enclave for the lifetime of the process. It is never persisted. The result-signing key travels inside the same split secret, so it too can only materialize inside the attested enclave. See [Key Management](/deep-dive/cofhe-components/key-management) for the ceremony that creates and distributes the shares. +The FHE secret key is never stored whole. It is split with Shamir secret sharing into six shares held by independent parties, with any three required for reconstruction (3-of-6). At boot, the attested enclave collects shares from the custodians, reconstructs the key in memory, and zeroizes the transient share material. The reconstructed key exists only inside the enclave for the lifetime of the process. It is never persisted. The result-signing key travels inside the same split secret, so it too can only materialize inside the attested enclave. See [Key Management](/cofhe/deep-dive/cofhe-components/key-management) for the ceremony that creates and distributes the shares. ## Result signing @@ -77,4 +77,4 @@ Teecryptor's signer address is registered onchain as `decryptResultSigner` in th ## Future plans -Teecryptor concentrates key custody at runtime in a single attested machine. The planned Threshold Network removes that concentration by decrypting through multi-party computation, where no party ever holds the full key. See [Future Plans](/deep-dive/research/future-plans). +Teecryptor concentrates key custody at runtime in a single attested machine. The planned Threshold Network removes that concentration by decrypting through multi-party computation, where no party ever holds the full key. See [Future Plans](/cofhe/deep-dive/research/future-plans). diff --git a/deep-dive/cofhe-components/teecryptor.mmd b/cofhe/deep-dive/cofhe-components/teecryptor.mmd similarity index 100% rename from deep-dive/cofhe-components/teecryptor.mmd rename to cofhe/deep-dive/cofhe-components/teecryptor.mmd diff --git a/deep-dive/cofhe-components/verify-commitments.mdx b/cofhe/deep-dive/cofhe-components/verify-commitments.mdx similarity index 91% rename from deep-dive/cofhe-components/verify-commitments.mdx rename to cofhe/deep-dive/cofhe-components/verify-commitments.mdx index 8c025f6d..063df54f 100644 --- a/deep-dive/cofhe-components/verify-commitments.mdx +++ b/cofhe/deep-dive/cofhe-components/verify-commitments.mdx @@ -52,7 +52,7 @@ That difference is why the registry exists. A result's handle is fixed onchain t {/* Diagram source: verify-commitments.mmd, beside this page. Edit it first, then re-run the archify build. */} -The TaskManager on the host chain, the verified input archive and the key store inside CoFHE, and the CommitmentRegistry on the registry chain, all feeding a recomputation and a hash comparison on your own machine +The TaskManager on the host chain, the verified input archive and the key store inside CoFHE, and the CommitmentRegistry on the registry chain, all feeding a recomputation and a hash comparison on your own machine @@ -85,7 +85,7 @@ One real event from Arbitrum Sepolia, decoded: | `input2` | `0x4765f9b1760b9612da755387f067d04051c2821bb4defc33ba58cbf940f00500` | | `ctHash` | `0xf0a73bae25878afcc52cf176616b3e3aa93f3ef6fa701ed61282cdd17df70500` | -Operation names come from `Utils.functionIdToString` in [`ICofhe.sol`](https://github.com/FhenixProtocol/cofhe-contracts/blob/master/contracts/ICofhe.sol), which also defines the type constants. Byte 30 holds the type in its low seven bits. Its high bit is set when the value was [trivially encrypted](/fhe-library/core-concepts/trivial-encryption), so mask the byte with `0x7f` before you compare it to those constants. Here every handle ends in `05 00`, which is `EUINT64_TFHE` in security zone 0. The same type, trivially encrypted, ends `85 00` and matches no constant until you mask it. +Operation names come from `Utils.functionIdToString` in [`ICofhe.sol`](https://github.com/FhenixProtocol/cofhe-contracts/blob/master/contracts/ICofhe.sol), which also defines the type constants. Byte 30 holds the type in its low seven bits. Its high bit is set when the value was [trivially encrypted](/cofhe/fhe-library/core-concepts/trivial-encryption), so mask the byte with `0x7f` before you compare it to those constants. Here every handle ends in `05 00`, which is `EUINT64_TFHE` in security zone 0. The same type, trivially encrypted, ends `85 00` and matches no constant until you mask it. An input handle is either another task's result, in which case you follow it and recurse, or an encrypted input. Encrypted inputs terminate the graph, and each one has its commitment onchain: @@ -147,11 +147,11 @@ cast call $REGISTRY "getHandles(bytes32,uint256,uint256)(bytes32[])" \ $VERSION 0 100 --rpc-url $REGISTRY_RPC ``` -Keep `limit` small. See [CommitmentRegistry](/deep-dive/cofhe-components/commitment-registry) for the write rules, the version state machine, and the rest of the read surface. +Keep `limit` small. See [CommitmentRegistry](/cofhe/deep-dive/cofhe-components/commitment-registry) for the write rules, the version state machine, and the rest of the read surface. ## Fetch the inputs -The [ZK Verifier](/deep-dive/cofhe-components/zk-verifier) archives every input it verifies, together with the proof that covered it. This store holds inputs and proofs only, not the keys. Objects are laid out by chain and security zone, sharded by the first four hex characters of the handle: +The [ZK Verifier](/cofhe/deep-dive/cofhe-components/zk-verifier) archives every input it verifies, together with the proof that covered it. This store holds inputs and proofs only, not the keys. Objects are laid out by chain and security zone, sharded by the first four hex characters of the handle: ```text cofhe/v1/chain/{chainId}/security-zone/{zone}/verified-inputs/{shard}/{handle} @@ -278,7 +278,7 @@ If all of these hold and the hashes still differ, you have a real discrepancy be ## Where this check runs in production -[Teecryptor](/deep-dive/cofhe-components/teecryptor) makes the same comparison inside its enclave on every decryption request. It hashes the ciphertext bytes it is about to decrypt and refuses any that do not match the commitment anchored onchain. Your audit and its gate read the same record, so a commitment you can check yourself is the same one that gates every decryption. +[Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) makes the same comparison inside its enclave on every decryption request. It hashes the ciphertext bytes it is about to decrypt and refuses any that do not match the commitment anchored onchain. Your audit and its gate read the same record, so a commitment you can check yourself is the same one that gates every decryption. ## Source diff --git a/deep-dive/cofhe-components/verify-commitments.mmd b/cofhe/deep-dive/cofhe-components/verify-commitments.mmd similarity index 100% rename from deep-dive/cofhe-components/verify-commitments.mmd rename to cofhe/deep-dive/cofhe-components/verify-commitments.mmd diff --git a/deep-dive/cofhe-components/zk-verifier-explorable.mdx b/cofhe/deep-dive/cofhe-components/zk-verifier-explorable.mdx similarity index 100% rename from deep-dive/cofhe-components/zk-verifier-explorable.mdx rename to cofhe/deep-dive/cofhe-components/zk-verifier-explorable.mdx diff --git a/deep-dive/cofhe-components/zk-verifier.mdx b/cofhe/deep-dive/cofhe-components/zk-verifier.mdx similarity index 87% rename from deep-dive/cofhe-components/zk-verifier.mdx rename to cofhe/deep-dive/cofhe-components/zk-verifier.mdx index 4e3bebd0..5c4f1048 100644 --- a/deep-dive/cofhe-components/zk-verifier.mdx +++ b/cofhe/deep-dive/cofhe-components/zk-verifier.mdx @@ -29,11 +29,11 @@ When providing ciphertexts as an input to a smart contract, users have to genera {/* Diagram source: zk-verifier.mmd, beside this page. Edit it first, then re-run the archify build. */} -Sequence diagram of the zk verifier path +Sequence diagram of the zk verifier path -Color marks the zone. Your app and the Client SDK run client side, your contract and the TaskManager on the host chain. The ZK Verifier and compute pipeline run offchain inside CoFHE, and the CommitmentRegistry sits on the registry chain. Hover any component or message in the [explorable version](/deep-dive/cofhe-components/zk-verifier-explorable). +Color marks the zone. Your app and the Client SDK run client side, your contract and the TaskManager on the host chain. The ZK Verifier and compute pipeline run offchain inside CoFHE, and the CommitmentRegistry sits on the registry chain. Hover any component or message in the [explorable version](/cofhe/deep-dive/cofhe-components/zk-verifier-explorable). The process of sending inputs to a smart contract: @@ -43,14 +43,14 @@ The process of sending inputs to a smart contract: 3. The ZK Verifier verifies each proof. If all are valid, it stores the encrypted values in the CT Server and signs one message approving the whole batch. 4. The ZK Verifier returns the handles and the batch approval to your app. 5. Your app sends the handles and the approval as inputs to a contract call. -6. The TaskManager verifies the batch signature and emits `InputVerified` per input. The [compute pipeline](/deep-dive/cofhe-components/compute-pipeline) picks those events up and posts a commitment for each input to the [CommitmentRegistry](/deep-dive/cofhe-components/commitment-registry), so the input becomes decryptable later. +6. The TaskManager verifies the batch signature and emits `InputVerified` per input. The [compute pipeline](/cofhe/deep-dive/cofhe-components/compute-pipeline) picks those events up and posts a commitment for each input to the [CommitmentRegistry](/cofhe/deep-dive/cofhe-components/commitment-registry), so the input becomes decryptable later. 7. The contract performs the actual logic. Most of this process is abstracted away. Steps 1 to 6 all happen behind the SDK and library calls, while step 7 (the actual logic) is up to you to write. ## Trust model -The ZK Verifier runs inside a hardware-attested TEE (Intel TDX). Its signing key is held as Shamir shares by independent partners and released only to the exact attested code image. Neither the operator nor anyone else can sign approvals outside the reviewed program. See [Key Management](/deep-dive/cofhe-components/key-management) for how shares are created and released. After a successful verification, the component stores the ciphertext bytes in the CT Server. It also archives the inputs and their proofs in a public Google Cloud Storage bucket for independent auditing. The repo ships the checking tool: [`verify_stored_ct.rs`](https://github.com/FhenixProtocol/zee-k-verifier/blob/main/zk-verifier/scripts/verify_stored_ct.rs) fetches a stored ciphertext and checks it against its commitment. [Verify a commitment offline](/deep-dive/cofhe-components/verify-commitments) covers the full procedure. +The ZK Verifier runs inside a hardware-attested TEE (Intel TDX). Its signing key is held as Shamir shares by independent partners and released only to the exact attested code image. Neither the operator nor anyone else can sign approvals outside the reviewed program. See [Key Management](/cofhe/deep-dive/cofhe-components/key-management) for how shares are created and released. After a successful verification, the component stores the ciphertext bytes in the CT Server. It also archives the inputs and their proofs in a public Google Cloud Storage bucket for independent auditing. The repo ships the checking tool: [`verify_stored_ct.rs`](https://github.com/FhenixProtocol/zee-k-verifier/blob/main/zk-verifier/scripts/verify_stored_ct.rs) fetches a stored ciphertext and checks it against its commitment. [Verify a commitment offline](/cofhe/deep-dive/cofhe-components/verify-commitments) covers the full procedure. The signed message is verified onchain by the TaskManager using `ecrecover`; the verifier's signer address is registered there as `verifierSigner`. diff --git a/deep-dive/cofhe-components/zk-verifier.mmd b/cofhe/deep-dive/cofhe-components/zk-verifier.mmd similarity index 100% rename from deep-dive/cofhe-components/zk-verifier.mmd rename to cofhe/deep-dive/cofhe-components/zk-verifier.mmd diff --git a/deep-dive/data-flows/decryption-request-flow-explorable.mdx b/cofhe/deep-dive/data-flows/decryption-request-flow-explorable.mdx similarity index 100% rename from deep-dive/data-flows/decryption-request-flow-explorable.mdx rename to cofhe/deep-dive/data-flows/decryption-request-flow-explorable.mdx diff --git a/deep-dive/data-flows/decryption-request-flow.mdx b/cofhe/deep-dive/data-flows/decryption-request-flow.mdx similarity index 80% rename from deep-dive/data-flows/decryption-request-flow.mdx rename to cofhe/deep-dive/data-flows/decryption-request-flow.mdx index bf81c848..4e40e32c 100644 --- a/deep-dive/data-flows/decryption-request-flow.mdx +++ b/cofhe/deep-dive/data-flows/decryption-request-flow.mdx @@ -4,7 +4,7 @@ sidebar_position: 3 description: "How CoFHE values get decrypted: decryptForTx with onchain publication, decryptForView with sealed output" --- -Decryption in CoFHE is SDK-driven and happens offchain, inside [Teecryptor](/deep-dive/cofhe-components/teecryptor). A contract's role is to grant access and, when the result should go onchain, to read it back after publication. +Decryption in CoFHE is SDK-driven and happens offchain, inside [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor). A contract's role is to grant access and, when the result should go onchain, to read it back after publication. **Contracts cannot request decryption onchain.** The TaskManager rejects decrypt tasks (`DecryptFunctionNotSupported`), and `FHE.decrypt` no longer exists in the FHE library. The coprocessor never pushes plaintexts into your contract. @@ -12,8 +12,8 @@ Decryption in CoFHE is SDK-driven and happens offchain, inside [Teecryptor](/dee There are two SDK entry points, one per destination: -- **`decryptForTx`**: returns the plaintext with a Teecryptor signature you can publish onchain. Guide: [Decrypt to Tx](/client-sdk/guides/decrypt-to-tx). -- **`decryptForView`**: returns the plaintext sealed to your [ACP](/client-sdk/guides/acps) (Access Control Permission), for UI display and offchain reads. Guide: [Decrypt to View](/client-sdk/guides/decrypt-to-view). +- **`decryptForTx`**: returns the plaintext with a Teecryptor signature you can publish onchain. Guide: [Decrypt to Tx](/cofhe/client-sdk/guides/decrypt-to-tx). +- **`decryptForView`**: returns the plaintext sealed to your [ACP](/cofhe/client-sdk/guides/acps) (Access Control Permission), for UI display and offchain reads. Guide: [Decrypt to View](/cofhe/client-sdk/guides/decrypt-to-view). A freshly computed handle may not be decryptable immediately: its ciphertext and commitment land shortly after the transaction. Until then Teecryptor answers with a retryable status and the SDK re-submits automatically. @@ -50,7 +50,7 @@ The request goes to Teecryptor with the handle, the host chain id, and the ACP. -Teecryptor runs two onchain checks at the same time. It reads the ACL grant on the host chain, and the handle's commitment in the [CommitmentRegistry](/deep-dive/cofhe-components/commitment-registry) on the registry chain. The two live on different chains, so neither check waits for the other. Teecryptor then fetches the ciphertext from the CT Server, exactly as stored, checks that the bytes hash to that commitment, and decrypts inside the attested enclave. See the [Teecryptor page](/deep-dive/cofhe-components/teecryptor) for the full pipeline. +Teecryptor runs two onchain checks at the same time. It reads the ACL grant on the host chain, and the handle's commitment in the [CommitmentRegistry](/cofhe/deep-dive/cofhe-components/commitment-registry) on the registry chain. The two live on different chains, so neither check waits for the other. Teecryptor then fetches the ciphertext from the CT Server, exactly as stored, checks that the bytes hash to that commitment, and decrypts inside the attested enclave. See the [Teecryptor page](/cofhe/deep-dive/cofhe-components/teecryptor) for the full pipeline. @@ -90,11 +90,11 @@ For `decryptForView`, Teecryptor never returns a bare plaintext. It encrypts the {/* Diagram source: decryption-request-flow.mmd, beside this page. Edit it first, then re-run the archify build. */} -Sequence diagram of the decryption flow +Sequence diagram of the decryption flow -Your app and the Client SDK run client side, your contract and the TaskManager on the host chain, Teecryptor offchain inside CoFHE, and the CommitmentRegistry on the registry chain. Hover any component or message in the [explorable version](/deep-dive/data-flows/decryption-request-flow-explorable). +Your app and the Client SDK run client side, your contract and the TaskManager on the host chain, Teecryptor offchain inside CoFHE, and the CommitmentRegistry on the registry chain. Hover any component or message in the [explorable version](/cofhe/deep-dive/data-flows/decryption-request-flow-explorable). ## Comparison @@ -109,4 +109,4 @@ Your app and the Client SDK run client side, your contract and the TaskManager o ## Future plans -Decryption is currently performed by Teecryptor inside a hardware-attested TEE. A multi-party Threshold Network is the planned successor; see [Future Plans](/deep-dive/research/future-plans). +Decryption is currently performed by Teecryptor inside a hardware-attested TEE. A multi-party Threshold Network is the planned successor; see [Future Plans](/cofhe/deep-dive/research/future-plans). diff --git a/deep-dive/data-flows/decryption-request-flow.mmd b/cofhe/deep-dive/data-flows/decryption-request-flow.mmd similarity index 100% rename from deep-dive/data-flows/decryption-request-flow.mmd rename to cofhe/deep-dive/data-flows/decryption-request-flow.mmd diff --git a/deep-dive/data-flows/encryption-request-flow-explorable.mdx b/cofhe/deep-dive/data-flows/encryption-request-flow-explorable.mdx similarity index 100% rename from deep-dive/data-flows/encryption-request-flow-explorable.mdx rename to cofhe/deep-dive/data-flows/encryption-request-flow-explorable.mdx diff --git a/deep-dive/data-flows/encryption-request-flow.mdx b/cofhe/deep-dive/data-flows/encryption-request-flow.mdx similarity index 70% rename from deep-dive/data-flows/encryption-request-flow.mdx rename to cofhe/deep-dive/data-flows/encryption-request-flow.mdx index e0d0e650..d75a82c7 100644 --- a/deep-dive/data-flows/encryption-request-flow.mdx +++ b/cofhe/deep-dive/data-flows/encryption-request-flow.mdx @@ -12,28 +12,28 @@ This page follows encrypted inputs from the plaintext in your application to han | **Your app** | Client side | The application that interacts with the user and the contracts | | **Client SDK** (`@cofhe/sdk`) | Client side | TypeScript library that encrypts inputs locally and submits them for verification | | **Your contract** | Host chain | Consumes the handles and the proof, and forwards them to the TaskManager | -| **[TaskManager](/deep-dive/cofhe-components/task-manager)** | Host chain | Verifies the ZK Verifier's batch signature when the inputs are used onchain | -| **[ZK Verifier](/deep-dive/cofhe-components/zk-verifier)** | CoFHE, offchain | Attested offchain component that verifies the proofs of every encrypted-input batch | +| **[TaskManager](/cofhe/deep-dive/cofhe-components/task-manager)** | Host chain | Verifies the ZK Verifier's batch signature when the inputs are used onchain | +| **[ZK Verifier](/cofhe/deep-dive/cofhe-components/zk-verifier)** | CoFHE, offchain | Attested offchain component that verifies the proofs of every encrypted-input batch | | **CT Server** | CoFHE, offchain | Stores the verified ciphertext bytes. Not drawn in the diagram; the ZK Verifier writes to it during verification | -| **[Compute pipeline](/deep-dive/cofhe-components/compute-pipeline)** | CoFHE, offchain | Picks up each `InputVerified` event and posts the commitment | -| **[CommitmentRegistry](/deep-dive/cofhe-components/commitment-registry)** | Registry chain | Records a commitment for every verified input | +| **[Compute pipeline](/cofhe/deep-dive/cofhe-components/compute-pipeline)** | CoFHE, offchain | Picks up each `InputVerified` event and posts the commitment | +| **[CommitmentRegistry](/cofhe/deep-dive/cofhe-components/commitment-registry)** | Registry chain | Records a commitment for every verified input | ## Flow diagram {/* Diagram source: encryption-request-flow.mmd, beside this page. Edit it first, then re-run the archify build. */} -Encrypted inputs travelling from your app through the Client SDK and ZK Verifier, onchain into your contract and the TaskManager, and finally anchored in the CommitmentRegistry by the compute pipeline +Encrypted inputs travelling from your app through the Client SDK and ZK Verifier, onchain into your contract and the TaskManager, and finally anchored in the CommitmentRegistry by the compute pipeline -Each color in the diagram is one zone from the table above. Hover any component or message in the [explorable version](/deep-dive/data-flows/encryption-request-flow-explorable). +Each color in the diagram is one zone from the table above. Hover any component or message in the [explorable version](/cofhe/deep-dive/data-flows/encryption-request-flow-explorable). ## Step-by-step flow -Install and initialize the Client SDK in your project. Full details are in the [installation guide](/client-sdk/introduction/installation). +Install and initialize the Client SDK in your project. Full details are in the [installation guide](/cofhe/client-sdk/introduction/installation). ```bash npm install @cofhe/sdk @@ -68,10 +68,10 @@ The ZK Verifier checks each proof inside its attested enclave. A valid proof sho -The application passes the handles and the proof to the contract as encrypted inputs. When the contract consumes them, the TaskManager's `batchVerifyInputs` checks the ZK Verifier's signature over the batch and emits an `InputVerified` event per input. The [compute pipeline](/deep-dive/cofhe-components/compute-pipeline) picks those events up and posts a commitment for each input to the CommitmentRegistry. Inputs are anchored onchain the same way every computed result is. +The application passes the handles and the proof to the contract as encrypted inputs. When the contract consumes them, the TaskManager's `batchVerifyInputs` checks the ZK Verifier's signature over the batch and emits an `InputVerified` event per input. The [compute pipeline](/cofhe/deep-dive/cofhe-components/compute-pipeline) picks those events up and posts a commitment for each input to the CommitmentRegistry. Inputs are anchored onchain the same way every computed result is. -Read more about the client-side API in [Encrypting Inputs](/client-sdk/guides/encrypting-inputs). +Read more about the client-side API in [Encrypting Inputs](/cofhe/client-sdk/guides/encrypting-inputs). diff --git a/deep-dive/data-flows/encryption-request-flow.mmd b/cofhe/deep-dive/data-flows/encryption-request-flow.mmd similarity index 100% rename from deep-dive/data-flows/encryption-request-flow.mmd rename to cofhe/deep-dive/data-flows/encryption-request-flow.mmd diff --git a/deep-dive/data-flows/fhe-operation-request-flow-explorable.mdx b/cofhe/deep-dive/data-flows/fhe-operation-request-flow-explorable.mdx similarity index 100% rename from deep-dive/data-flows/fhe-operation-request-flow-explorable.mdx rename to cofhe/deep-dive/data-flows/fhe-operation-request-flow-explorable.mdx diff --git a/deep-dive/data-flows/fhe-operation-request-flow.mdx b/cofhe/deep-dive/data-flows/fhe-operation-request-flow.mdx similarity index 72% rename from deep-dive/data-flows/fhe-operation-request-flow.mdx rename to cofhe/deep-dive/data-flows/fhe-operation-request-flow.mdx index 26fc96b3..ec695d98 100644 --- a/deep-dive/data-flows/fhe-operation-request-flow.mdx +++ b/cofhe/deep-dive/data-flows/fhe-operation-request-flow.mdx @@ -12,26 +12,26 @@ This page follows a single FHE operation from the contract call that requests it |-----------|---------|-------------| | **Your contract** | Host chain | Requests FHE operations through the FHE.sol library | | **FHE.sol** | Host chain | The Solidity library providing FHE operation functions | -| **[TaskManager](/deep-dive/cofhe-components/task-manager)** | Host chain | Validates requests, checks the [ACL](/deep-dive/cofhe-components/acl), and emits task events | -| **[Compute pipeline](/deep-dive/cofhe-components/compute-pipeline)** | CoFHE, offchain | Picks up task events, validates and orders the work, executes it, and commits the result | -| **[CommitmentRegistry](/deep-dive/cofhe-components/commitment-registry)** | Registry chain | Records a hash commitment for every result ciphertext | +| **[TaskManager](/cofhe/deep-dive/cofhe-components/task-manager)** | Host chain | Validates requests, checks the [ACL](/cofhe/deep-dive/cofhe-components/acl), and emits task events | +| **[Compute pipeline](/cofhe/deep-dive/cofhe-components/compute-pipeline)** | CoFHE, offchain | Picks up task events, validates and orders the work, executes it, and commits the result | +| **[CommitmentRegistry](/cofhe/deep-dive/cofhe-components/commitment-registry)** | Registry chain | Records a hash commitment for every result ciphertext | ## Flow diagram {/* Diagram source: fhe-operation-request-flow.mmd, beside this page. Edit it first, then re-run the archify build. */} -Sequence diagram of the fhe operation flow +Sequence diagram of the fhe operation flow -Each color is one zone from the table above. Hover any component or message in the [explorable version](/deep-dive/data-flows/fhe-operation-request-flow-explorable). +Each color is one zone from the table above. Hover any component or message in the [explorable version](/cofhe/deep-dive/data-flows/fhe-operation-request-flow-explorable). ## Step-by-step flow -The application encrypts its input client-side and proves it valid, producing an encrypted-input handle plus a batch proof the contract can accept. The [Encryption Request Flow](/deep-dive/data-flows/encryption-request-flow) covers this step. +The application encrypts its input client-side and proves it valid, producing an encrypted-input handle plus a batch proof the contract can accept. The [Encryption Request Flow](/cofhe/deep-dive/data-flows/encryption-request-flow) covers this step. This step happens on the client side, before any blockchain interaction. @@ -72,7 +72,7 @@ The TaskManager is the gateway for all FHE operation requests. It: -The [compute pipeline](/deep-dive/cofhe-components/compute-pipeline) subscribes to TaskManager events on every host chain and picks up the `TaskCreated` event. It checks that the operation is well formed and that the inputs it references exist. An operation that arrives before its inputs finish computing is deferred and released once they land. +The [compute pipeline](/cofhe/deep-dive/cofhe-components/compute-pipeline) subscribes to TaskManager events on every host chain and picks up the `TaskCreated` event. It checks that the operation is well formed and that the inputs it references exist. An operation that arrives before its inputs finish computing is deferred and released once they land. diff --git a/deep-dive/data-flows/fhe-operation-request-flow.mmd b/cofhe/deep-dive/data-flows/fhe-operation-request-flow.mmd similarity index 100% rename from deep-dive/data-flows/fhe-operation-request-flow.mmd rename to cofhe/deep-dive/data-flows/fhe-operation-request-flow.mmd diff --git a/deep-dive/research/future-plans.mdx b/cofhe/deep-dive/research/future-plans.mdx similarity index 89% rename from deep-dive/research/future-plans.mdx rename to cofhe/deep-dive/research/future-plans.mdx index 42766c75..db43ee1c 100644 --- a/deep-dive/research/future-plans.mdx +++ b/cofhe/deep-dive/research/future-plans.mdx @@ -23,13 +23,13 @@ Outlined here is a non-exhaustive list of trust points, centralized components, ## The path to multi-party computation -CoFHE runs two TEE components today, [Teecryptor](/deep-dive/cofhe-components/teecryptor) and the [ZK Verifier](/deep-dive/cofhe-components/zk-verifier). Both move to multi-party computation, and they move together. No TEE stays on the critical path after that. +CoFHE runs two TEE components today, [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) and the [ZK Verifier](/cofhe/deep-dive/cofhe-components/zk-verifier). Both move to multi-party computation, and they move together. No TEE stays on the critical path after that. Decryption becomes a Threshold Network. Independent parties decrypt through multi-party computation, so no single party (and no single machine) ever holds the FHE key. Robustness goals for it include a t-out-of-n protocol (no requirement that every party stays online), party share rotation, and full protocol key rotation. Input verification follows the same model. Each partner runs ZK verification on its own side, instead of one attested enclave checking every proof and signing the batch alone. -See [Research in Fhenix](/deep-dive/research/research-in-fhenix) for the threshold decryption protocol behind this plan. +See [Research in Fhenix](/cofhe/deep-dive/research/research-in-fhenix) for the threshold decryption protocol behind this plan. ## Upcoming features diff --git a/deep-dive/research/research-in-fhenix.mdx b/cofhe/deep-dive/research/research-in-fhenix.mdx similarity index 78% rename from deep-dive/research/research-in-fhenix.mdx rename to cofhe/deep-dive/research/research-in-fhenix.mdx index 2ec2d6e0..27eb542e 100644 --- a/deep-dive/research/research-in-fhenix.mdx +++ b/cofhe/deep-dive/research/research-in-fhenix.mdx @@ -8,6 +8,6 @@ Our research explores novel cryptographic techniques to push the boundaries of F ## Threshold decryption for FHE -Decryption in CoFHE is currently served by [Teecryptor](/deep-dive/cofhe-components/teecryptor), a TEE-based component. The research below is the path to its planned decentralized successor, the [Threshold Network](/deep-dive/research/future-plans). +Decryption in CoFHE is currently served by [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor), a TEE-based component. The research below is the path to its planned decentralized successor, the [Threshold Network](/cofhe/deep-dive/research/future-plans). We designed a new threshold FHE decryption protocol that improves throughput by roughly 20,000x and cuts latency by up to 37x relative to the prior state of the art. This is achieved by securely removing ciphertext noise with an efficient MPC-based approach, eliminating the need for noise flooding while maintaining strong simulation-based security. diff --git a/fhe-library/confidential-contracts/calling-from-contracts.mdx b/cofhe/fhe-library/confidential-contracts/calling-from-contracts.mdx similarity index 85% rename from fhe-library/confidential-contracts/calling-from-contracts.mdx rename to cofhe/fhe-library/confidential-contracts/calling-from-contracts.mdx index 6198cba2..83c1fa91 100644 --- a/fhe-library/confidential-contracts/calling-from-contracts.mdx +++ b/cofhe/fhe-library/confidential-contracts/calling-from-contracts.mdx @@ -3,11 +3,11 @@ title: "Call a token from your contract" description: "Move confidential tokens from another contract by sharing encrypted amounts with the token and receiving what it returns" --- -When your contract moves confidential tokens, it passes encrypted amounts to the token and gets encrypted amounts back. Both directions use `sharedEuint64`, a handle tagged with who shared it and with whom. This page shows the pattern on a vault, and it applies to [FHERC20](/fhe-library/confidential-contracts/fherc20/overview) and [ERC20Confidential](/fhe-library/confidential-contracts/dual-mode/overview) alike. +When your contract moves confidential tokens, it passes encrypted amounts to the token and gets encrypted amounts back. Both directions use `sharedEuint64`, a handle tagged with who shared it and with whom. This page shows the pattern on a vault, and it applies to [FHERC20](/cofhe/fhe-library/confidential-contracts/fherc20/overview) and [ERC20Confidential](/cofhe/fhe-library/confidential-contracts/dual-mode/overview) alike. ## Why amounts cross as shared values -FHE operations check the permission of the contract performing them, not of whoever called it. Suppose a token accepted a bare `euint64` from any caller. That caller could pass a handle only the token may use, such as someone's balance, and get back a value derived from it. A share records the sharer and the intended receiver, and lasts one transaction, so the receiver can check who handed the value over. [Passing encrypted values between contracts](/fhe-library/core-concepts/inputs#passing-encrypted-values-between-contracts) covers the mechanism. +FHE operations check the permission of the contract performing them, not of whoever called it. Suppose a token accepted a bare `euint64` from any caller. That caller could pass a handle only the token may use, such as someone's balance, and get back a value derived from it. A share records the sharer and the intended receiver, and lasts one transaction, so the receiver can check who handed the value over. [Passing encrypted values between contracts](/cofhe/fhe-library/core-concepts/inputs#passing-encrypted-values-between-contracts) covers the mechanism. For a token call, that means two steps around every call: @@ -74,13 +74,13 @@ Three details carry the design: - **Credit what moved, not what was asked.** A transfer that exceeds the sender's balance moves zero instead of reverting. The vault credits `received`, the amount the token returns, so a failed deposit credits nothing. - **Clamp before you send.** `withdraw` uses `FHE.select` to replace an over-deposit request with zero. The contract cannot revert on an encrypted comparison without revealing it. -- **Persist with `allowThis`.** A received handle carries access for this transaction only. Values you store must get `FHE.allowThis`, and `FHE.allow` for the account that should decrypt them. See [access control](/fhe-library/core-concepts/access-control). +- **Persist with `allowThis`.** A received handle carries access for this transaction only. Values you store must get `FHE.allowThis`, and `FHE.allow` for the account that should decrypt them. See [access control](/cofhe/fhe-library/core-concepts/access-control). `IERC7984` is the interface both token families implement, so the vault works with either. The shared overloads of `confidentialTransfer` and `confidentialTransferFrom` are selected by the `sharedEuint64` argument type. ## Call the vault from your app -`confidentialTransferFrom` runs with the vault as `msg.sender`, so the depositor must first make the vault an [operator](/fhe-library/confidential-contracts/fherc20/operators). Without it, the deposit reverts with `FHERC20UnauthorizedSpender` on FHERC20, or `ERC20ConfidentialUnauthorizedSpender` on ERC20Confidential. +`confidentialTransferFrom` runs with the vault as `msg.sender`, so the depositor must first make the vault an [operator](/cofhe/fhe-library/confidential-contracts/fherc20/operators). Without it, the deposit reverts with `FHERC20UnauthorizedSpender` on FHERC20, or `ERC20ConfidentialUnauthorizedSpender` on ERC20Confidential. Encrypt the amount with the vault as the consuming contract, because the vault calls `FHE.asEuint64`, not the token: @@ -99,7 +99,7 @@ const [amount, inputProof] = await client await vault.deposit(amount, inputProof); ``` -An input encrypted for the token instead of the vault fails with `InvalidSigner`. The same happens when one account encrypts and another sends the transaction: encrypt with the client of the account that calls the vault. See [encrypting inputs](/client-sdk/guides/encrypting-inputs). +An input encrypted for the token instead of the vault fails with `InvalidSigner`. The same happens when one account encrypts and another sends the transaction: encrypt with the client of the account that calls the vault. See [encrypting inputs](/cofhe/client-sdk/guides/encrypting-inputs). ## What goes wrong @@ -110,8 +110,8 @@ An input encrypted for the token instead of the vault fails with `InvalidSigner` | `SenderNotAllowed` | Your contract shared a handle it is not allowed to use | | `InvalidSigner` | The input was encrypted for a different contract or account | -These errors come from the TaskManager. See [common errors](/fhe-library/core-concepts/common-errors). +These errors come from the TaskManager. See [common errors](/cofhe/fhe-library/core-concepts/common-errors). ## Receive tokens with a callback -To react when tokens arrive, rather than pulling them, implement `IERC7984Receiver`. The token calls it during `confidentialTransferAndCall` with the amount as a `sharedEuint64`, which you receive with `FHE.receiveEuint64Param`. See [transfer callbacks](/fhe-library/confidential-contracts/fherc20/transfer-callbacks). +To react when tokens arrive, rather than pulling them, implement `IERC7984Receiver`. The token calls it during `confidentialTransferAndCall` with the amount as a `sharedEuint64`, which you receive with `FHE.receiveEuint64Param`. See [transfer callbacks](/cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks). diff --git a/fhe-library/confidential-contracts/dual-mode/best-practices.mdx b/cofhe/fhe-library/confidential-contracts/dual-mode/best-practices.mdx similarity index 75% rename from fhe-library/confidential-contracts/dual-mode/best-practices.mdx rename to cofhe/fhe-library/confidential-contracts/dual-mode/best-practices.mdx index c0d69720..85f6cb75 100644 --- a/fhe-library/confidential-contracts/dual-mode/best-practices.mdx +++ b/cofhe/fhe-library/confidential-contracts/dual-mode/best-practices.mdx @@ -9,32 +9,32 @@ These are the mistakes that are easiest to make with `ERC20Confidential`. Each o Privacy covers balances and transfers inside the confidential layer, not the boundary. The amount passed to `shield` is in the call data and in the `TokensShielded` event. The amount passed to `unshield(uint64)` is in the call data, and every claim reveals its amount when it settles. -Tell users that what they move in and out is visible. A user who shields 1,000 tokens and later unshields 1,000 links the two. See [shield and unshield](/fhe-library/confidential-contracts/dual-mode/shield-unshield). +Tell users that what they move in and out is visible. A user who shields 1,000 tokens and later unshields 1,000 links the two. See [shield and unshield](/cofhe/fhe-library/confidential-contracts/dual-mode/shield-unshield). ## Check the amount that actually moved -A confidential transfer or unshield of more than the balance does not revert. It moves zero. Every transfer returns the amount that moved as a `sharedEuint64`, so a contract that credits a user should credit that returned amount, never the amount it asked for. See [call a token from your contract](/fhe-library/confidential-contracts/calling-from-contracts). +A confidential transfer or unshield of more than the balance does not revert. It moves zero. Every transfer returns the amount that moved as a `sharedEuint64`, so a contract that credits a user should credit that returned amount, never the amount it asked for. See [call a token from your contract](/cofhe/fhe-library/confidential-contracts/calling-from-contracts). ## Work in confidential units -Transfers, `unshield`, and `_confidentialMint` take confidential units, while `shield` and every ERC-20 function take public base units. For an 18-decimal token one confidential unit is 10^12 base units, and `shield` leaves anything below that in the public balance. Read `confidentialDecimals()` instead of assuming 6. See [decimals and units](/fhe-library/confidential-contracts/dual-mode/overview#decimals-and-units). +Transfers, `unshield`, and `_confidentialMint` take confidential units, while `shield` and every ERC-20 function take public base units. For an 18-decimal token one confidential unit is 10^12 base units, and `shield` leaves anything below that in the public balance. Read `confidentialDecimals()` instead of assuming 6. See [decimals and units](/cofhe/fhe-library/confidential-contracts/dual-mode/overview#decimals-and-units). ## Use the plaintext supply, or sync before reading the handle -`confidentialTotalSupplyPlaintext()` is always current. The `confidentialTotalSupply()` handle goes stale when someone transfers public tokens straight to the pool, and stays stale until anyone calls `syncConfidentialTotalSupply()`. It is also the zero handle until the first shield. See [what total supply counts](/fhe-library/confidential-contracts/dual-mode/dual-balance-model#what-total-supply-counts). +`confidentialTotalSupplyPlaintext()` is always current. The `confidentialTotalSupply()` handle goes stale when someone transfers public tokens straight to the pool, and stays stale until anyone calls `syncConfidentialTotalSupply()`. It is also the zero handle until the first shield. See [what total supply counts](/cofhe/fhe-library/confidential-contracts/dual-mode/dual-balance-model#what-total-supply-counts). ## Gate both balances if you freeze accounts -`_beforeConfidentialMove` covers confidential transfers and unshield only. A freeze built on it alone still lets the account use its public balance, shield, and receive claim payouts. Override `_update` as well. See [freeze accounts](/fhe-library/confidential-contracts/dual-mode/extending#freeze-accounts). +`_beforeConfidentialMove` covers confidential transfers and unshield only. A freeze built on it alone still lets the account use its public balance, shield, and receive claim payouts. Override `_update` as well. See [freeze accounts](/cofhe/fhe-library/confidential-contracts/dual-mode/extending#freeze-accounts). ## Backfill the observer when you set it -A compliance observer only gets access to handles created after it is set. Call `grantObserverPast` with the existing balance handles, or the observer cannot read balances that have not moved since. See [add a compliance observer](/fhe-library/confidential-contracts/dual-mode/extending#add-a-compliance-observer). +A compliance observer only gets access to handles created after it is set. Call `grantObserverPast` with the existing balance handles, or the observer cannot read balances that have not moved since. See [add a compliance observer](/cofhe/fhe-library/confidential-contracts/dual-mode/extending#add-a-compliance-observer). ## Keep operators short-lived -A confidential operator can move any amount of the holder's confidential balance until its deadline. It is separate from the public allowance: `approve` grants nothing on the confidential side, and `setOperator` grants nothing on the public side. Set a deadline that covers the action you need, and set it to `0` when you are done. See [operators](/fhe-library/confidential-contracts/dual-mode/confidential-operations#operators). +A confidential operator can move any amount of the holder's confidential balance until its deadline. It is separate from the public allowance: `approve` grants nothing on the confidential side, and `setOperator` grants nothing on the public side. Set a deadline that covers the action you need, and set it to `0` when you are done. See [operators](/cofhe/fhe-library/confidential-contracts/dual-mode/confidential-operations#operators). ## Link the library and enable the optimizer -Deploy `ERC20ConfidentialLib` from `fhenix-confidential-contracts@0.4.0` and link every token to it; the address cannot change after deployment. Compile with the optimizer on, so added functions do not push the token past the 24 KB contract size limit. See [link the shared library](/fhe-library/confidential-contracts/overview#link-the-shared-library). +Deploy `ERC20ConfidentialLib` from `fhenix-confidential-contracts@0.4.0` and link every token to it; the address cannot change after deployment. Compile with the optimizer on, so added functions do not push the token past the 24 KB contract size limit. See [link the shared library](/cofhe/fhe-library/confidential-contracts/overview#link-the-shared-library). diff --git a/fhe-library/confidential-contracts/dual-mode/confidential-operations.mdx b/cofhe/fhe-library/confidential-contracts/dual-mode/confidential-operations.mdx similarity index 82% rename from fhe-library/confidential-contracts/dual-mode/confidential-operations.mdx rename to cofhe/fhe-library/confidential-contracts/dual-mode/confidential-operations.mdx index 530fcc90..d15a29b4 100644 --- a/fhe-library/confidential-contracts/dual-mode/confidential-operations.mdx +++ b/cofhe/fhe-library/confidential-contracts/dual-mode/confidential-operations.mdx @@ -3,7 +3,7 @@ title: "Confidential transfers and operators" description: "How encrypted transfers and operators work on ERC20Confidential, and where they differ from FHERC20" --- -`ERC20Confidential` moves confidential balances with the same functions as [FHERC20](/fhe-library/confidential-contracts/fherc20/core-features). This page lists those functions and the few places where `ERC20Confidential` behaves differently. Read the FHERC20 page for the full behavior of each overload. +`ERC20Confidential` moves confidential balances with the same functions as [FHERC20](/cofhe/fhe-library/confidential-contracts/fherc20/core-features). This page lists those functions and the few places where `ERC20Confidential` behaves differently. Read the FHERC20 page for the full behavior of each overload. ## The transfer functions @@ -29,7 +29,7 @@ const [amount, inputProof] = await client await token['confidentialTransfer(address,bytes32,bytes)'](recipient, amount, inputProof); ``` -The account that encrypts the input must be the account that sends the transaction. For calls from a contract, see [call a token from your contract](/fhe-library/confidential-contracts/calling-from-contracts). +The account that encrypts the input must be the account that sends the transaction. For calls from a contract, see [call a token from your contract](/cofhe/fhe-library/confidential-contracts/calling-from-contracts). As on FHERC20, a transfer of more than the balance does not revert. It moves zero, and the returned amount decrypts to zero. @@ -41,9 +41,9 @@ As on FHERC20, a transfer of more than the balance does not revert. It moves zer | Caller is not `from` or an operator | `ERC20ConfidentialUnauthorizedSpender(holder, spender)` | `FHERC20UnauthorizedSpender(holder, spender)` | | `to` is the zero address | `ConfidentialInvalidReceiver(address(0))` | `FHERC20InvalidReceiver(address(0))` | | Hook before each move | `_beforeConfidentialMove(from, to)` | None | -| Indicator updates | On the separate [indicator token](/fhe-library/confidential-contracts/dual-mode/dual-balance-model#the-indicator-token) | On the token's own `balanceOf` | +| Indicator updates | On the separate [indicator token](/cofhe/fhe-library/confidential-contracts/dual-mode/dual-balance-model#the-indicator-token) | On the token's own `balanceOf` | -`_beforeConfidentialMove` runs before all eight transfer functions and both `unshield` overloads. It does nothing by default. Override it to freeze accounts or pause the confidential side; see [extend ERC20Confidential](/fhe-library/confidential-contracts/dual-mode/extending). +`_beforeConfidentialMove` runs before all eight transfer functions and both `unshield` overloads. It does nothing by default. Override it to freeze accounts or pause the confidential side; see [extend ERC20Confidential](/cofhe/fhe-library/confidential-contracts/dual-mode/extending). All eight transfer functions and both `unshield` overloads are `nonReentrant`, so a callback cannot call another transfer or `unshield` on the same token. @@ -56,13 +56,13 @@ const oneHour = Math.floor(Date.now() / 1000) + 3600; await token.setOperator(operatorAddress, oneHour); ``` -`isOperator(holder, spender)` returns `true` while `block.timestamp` is at or before the deadline, and always returns `true` when `holder` and `spender` are the same address. Setting the deadline to `0` revokes the operator. Each call emits `OperatorSet(holder, operator, until)`. For the operator model in depth, see [operators](/fhe-library/confidential-contracts/fherc20/operators). +`isOperator(holder, spender)` returns `true` while `block.timestamp` is at or before the deadline, and always returns `true` when `holder` and `spender` are the same address. Setting the deadline to `0` revokes the operator. Each call emits `OperatorSet(holder, operator, until)`. For the operator model in depth, see [operators](/cofhe/fhe-library/confidential-contracts/fherc20/operators). Confidential operators and public allowances are separate. `approve` and `transferFrom` keep working on the public balance and have no effect on the confidential one, and `setOperator` grants nothing on the public side. ## Transfers with a callback -`confidentialTransferAndCall` and `confidentialTransferFromAndCall` call `onConfidentialTransferReceived` on the recipient after the transfer, using the same `IERC7984Receiver` interface as FHERC20. If the receiver returns an encrypted `false`, the token moves the amount back to the sender. See [transfer callbacks](/fhe-library/confidential-contracts/fherc20/transfer-callbacks) for how to write a receiver. +`confidentialTransferAndCall` and `confidentialTransferFromAndCall` call `onConfidentialTransferReceived` on the recipient after the transfer, using the same `IERC7984Receiver` interface as FHERC20. If the receiver returns an encrypted `false`, the token moves the amount back to the sender. See [transfer callbacks](/cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks) for how to write a receiver. ## Events diff --git a/fhe-library/confidential-contracts/dual-mode/dual-balance-model.mdx b/cofhe/fhe-library/confidential-contracts/dual-mode/dual-balance-model.mdx similarity index 98% rename from fhe-library/confidential-contracts/dual-mode/dual-balance-model.mdx rename to cofhe/fhe-library/confidential-contracts/dual-mode/dual-balance-model.mdx index 96309690..af69265e 100644 --- a/fhe-library/confidential-contracts/dual-mode/dual-balance-model.mdx +++ b/cofhe/fhe-library/confidential-contracts/dual-mode/dual-balance-model.mdx @@ -60,7 +60,7 @@ The indicator's `transfer`, `transferFrom`, `approve`, and `allowance` revert wi ## Read both balances -The public balance is a plain view call. The confidential balance is a handle, which the holder decrypts with an Access Control Permission (ACP) through [`decryptForView`](/client-sdk/guides/decrypt-to-view): +The public balance is a plain view call. The confidential balance is a handle, which the holder decrypts with an Access Control Permission (ACP) through [`decryptForView`](/cofhe/client-sdk/guides/decrypt-to-view): ```typescript import { FheTypes } from '@cofhe/sdk'; diff --git a/fhe-library/confidential-contracts/dual-mode/extending.mdx b/cofhe/fhe-library/confidential-contracts/dual-mode/extending.mdx similarity index 95% rename from fhe-library/confidential-contracts/dual-mode/extending.mdx rename to cofhe/fhe-library/confidential-contracts/dual-mode/extending.mdx index 072c57e1..8dcf4016 100644 --- a/fhe-library/confidential-contracts/dual-mode/extending.mdx +++ b/cofhe/fhe-library/confidential-contracts/dual-mode/extending.mdx @@ -5,7 +5,7 @@ description: "Freeze accounts, add a compliance observer, mint confidentially, a `ERC20Confidential` exposes hooks and library functions for the policies a regulated or product-specific token needs. This page shows each one with a contract that compiles against `fhenix-confidential-contracts@0.4.0`. None of them is active unless your contract wires it in. -Every contract here inherits `ERC20Confidential`, so it must be [linked to `ERC20ConfidentialLib`](/fhe-library/confidential-contracts/overview#link-the-shared-library) when you deploy it. +Every contract here inherits `ERC20Confidential`, so it must be [linked to `ERC20ConfidentialLib`](/cofhe/fhe-library/confidential-contracts/overview#link-the-shared-library) when you deploy it. ## Freeze accounts @@ -87,13 +87,13 @@ contract ObservedToken is ERC20Confidential, Ownable { Grants only cover handles created after the observer is set. A balance that has not moved since then is still unreadable to the observer. To grant access to older handles, collect them, for example from `confidentialBalanceOf` and past `ConfidentialTransfer` events, and pass them to `grantObserverPast`. It emits `ObserverPastGranted(observer, count)` and reverts with `NoObserverSet` if no observer is set. Pass only handles this token created; on CoFHE a handle the token is not allowed on makes the whole call revert. -The observer reads values the same way a holder does, with [`decryptForView`](/client-sdk/guides/decrypt-to-view). +The observer reads values the same way a holder does, with [`decryptForView`](/cofhe/client-sdk/guides/decrypt-to-view). Changing the observer does not revoke the old observer's access to handles it was already granted. ## Mint straight into confidential balances -`_confidentialMint(address to, uint64 amount)` mints `amount * rate` public tokens into the [pool](/fhe-library/confidential-contracts/dual-mode/dual-balance-model#where-the-backing-tokens-sit) and credits `amount` confidential units to `to`. The amount is in confidential units and is public in your call data. The recipient never holds the tokens publicly. +`_confidentialMint(address to, uint64 amount)` mints `amount * rate` public tokens into the [pool](/cofhe/fhe-library/confidential-contracts/dual-mode/dual-balance-model#where-the-backing-tokens-sit) and credits `amount` confidential units to `to`. The amount is in confidential units and is public in your call data. The recipient never holds the tokens publicly. ```solidity function mintConfidential(address to, uint64 amount) external onlyOwner { diff --git a/fhe-library/confidential-contracts/dual-mode/overview.mdx b/cofhe/fhe-library/confidential-contracts/dual-mode/overview.mdx similarity index 77% rename from fhe-library/confidential-contracts/dual-mode/overview.mdx rename to cofhe/fhe-library/confidential-contracts/dual-mode/overview.mdx index bb3291ec..9f5989fa 100644 --- a/fhe-library/confidential-contracts/dual-mode/overview.mdx +++ b/cofhe/fhe-library/confidential-contracts/dual-mode/overview.mdx @@ -14,7 +14,7 @@ Each holder has two balances in the same contract: `shield` moves tokens from the public balance into the confidential one, and `unshield` plus `claimUnshielded` move them back. -On an [FHERC20](/fhe-library/confidential-contracts/fherc20/overview) token, the ERC-20 surface is only an indicator and its transfers revert. Here it is real, so `balanceOfIsIndicator()` returns `false` and `indicatorTick()` returns `0`. +On an [FHERC20](/cofhe/fhe-library/confidential-contracts/fherc20/overview) token, the ERC-20 surface is only an indicator and its transfers revert. Here it is real, so `balanceOfIsIndicator()` returns `false` and `indicatorTick()` returns `0`. | | `ERC20Confidential` | `FHERC20` | | --- | --- | --- | @@ -23,7 +23,7 @@ On an [FHERC20](/fhe-library/confidential-contracts/fherc20/overview) token, the | ERC-20 transfers | Work | Revert | | Needs `ERC20ConfidentialLib` linked | Yes | No | -Pick `ERC20Confidential` for a new token that needs both modes. To add privacy to a token that is already deployed, use a [wrapper](/fhe-library/confidential-contracts/fherc20/fherc20-wrapper) instead. +Pick `ERC20Confidential` for a new token that needs both modes. To add privacy to a token that is already deployed, use a [wrapper](/cofhe/fhe-library/confidential-contracts/fherc20/fherc20-wrapper) instead. ## A minimal token @@ -44,7 +44,7 @@ contract DualToken is ERC20Confidential { `_mint` is the OpenZeppelin function, so this mints public tokens. Holders call `shield` to make them confidential. -The constructor also deploys a small indicator token that wallets can track. See [how the two balances relate](/fhe-library/confidential-contracts/dual-mode/dual-balance-model#the-indicator-token). +The constructor also deploys a small indicator token that wallets can track. See [how the two balances relate](/cofhe/fhe-library/confidential-contracts/dual-mode/dual-balance-model#the-indicator-token). ## Decimals and units @@ -58,7 +58,7 @@ For an 18-decimal token the rate is 10^12. Shielding `1 ether` credits `1_000_00 ## Deploy it -`ERC20Confidential` and `ERC20ConfidentialUpgradeable` call into the external `ERC20ConfidentialLib`, so you must deploy that library and link it before you deploy the token. See [link the shared library](/fhe-library/confidential-contracts/overview#link-the-shared-library). For the upgradeable variant, see [upgradeable tokens](/fhe-library/confidential-contracts/upgradeable). +`ERC20Confidential` and `ERC20ConfidentialUpgradeable` call into the external `ERC20ConfidentialLib`, so you must deploy that library and link it before you deploy the token. See [link the shared library](/cofhe/fhe-library/confidential-contracts/overview#link-the-shared-library). For the upgradeable variant, see [upgradeable tokens](/cofhe/fhe-library/confidential-contracts/upgradeable). Enable the Solidity optimizer. `DualToken` compiles to about 16 KB of bytecode with the optimizer off, and a token with a few extra functions grows quickly toward the 24 KB limit. @@ -67,16 +67,16 @@ Enable the Solidity optimizer. `DualToken` compiles to about 16 KB of bytecode w ## Pages in this section - + The pool that backs confidential balances, total supply, and the indicator token. - + Move tokens between the public and the confidential balance. - + How encrypted transfers differ from FHERC20. - + Freeze accounts, add a compliance observer, mint confidentially, or bring your own ledger. diff --git a/fhe-library/confidential-contracts/dual-mode/shield-unshield.mdx b/cofhe/fhe-library/confidential-contracts/dual-mode/shield-unshield.mdx similarity index 84% rename from fhe-library/confidential-contracts/dual-mode/shield-unshield.mdx rename to cofhe/fhe-library/confidential-contracts/dual-mode/shield-unshield.mdx index 0314e8d8..43ecf3ce 100644 --- a/fhe-library/confidential-contracts/dual-mode/shield-unshield.mdx +++ b/cofhe/fhe-library/confidential-contracts/dual-mode/shield-unshield.mdx @@ -5,7 +5,7 @@ description: "Move ERC20Confidential tokens from the public balance into the enc `shield` moves tokens from a holder's public balance into their confidential balance in one transaction. Going back takes two: `unshield` burns the confidential amount and opens a claim, and `claimUnshielded` pays out public tokens once the amount is decrypted. This page covers both directions and the claim lifecycle. -Amounts in this page use the [conversion rate](/fhe-library/confidential-contracts/dual-mode/overview#decimals-and-units): for an 18-decimal token, one confidential unit is 10^12 public base units. +Amounts in this page use the [conversion rate](/cofhe/fhe-library/confidential-contracts/dual-mode/overview#decimals-and-units): for an 18-decimal token, one confidential unit is 10^12 public base units. ## Shield public tokens @@ -15,7 +15,7 @@ Amounts in this page use the [conversion rate](/fhe-library/confidential-contrac await token.shield(ethers.parseEther('10')); ``` -The token rounds `amount` down to a multiple of the rate. It moves the rounded amount into the [pool](/fhe-library/confidential-contracts/dual-mode/dual-balance-model#where-the-backing-tokens-sit) and credits `amount / rate` confidential units to the caller. The remainder never leaves the public balance. If the rounded amount is zero, `shield` reverts with `AmountTooSmallForConfidentialPrecision`. +The token rounds `amount` down to a multiple of the rate. It moves the rounded amount into the [pool](/cofhe/fhe-library/confidential-contracts/dual-mode/dual-balance-model#where-the-backing-tokens-sit) and credits `amount / rate` confidential units to the caller. The remainder never leaves the public balance. If the rounded amount is zero, `shield` reverts with `AmountTooSmallForConfidentialPrecision`. `shield` always acts on the caller's own tokens and credits the caller. There is no `shield` for another account and no approval involved. @@ -37,7 +37,7 @@ The shielded amount is public: it appears in the call data and in these events. | unshield(uint64 amount) | A wallet or a contract | Public, in confidential units | | unshield(sharedEuint64 amount) | A contract that holds an encrypted amount | Encrypted until the claim reveals it | -The plaintext overload puts the amount in the call data. The encrypted overload keeps it hidden until the claim, but only a contract can call it, because the caller creates the argument with `FHE.shareEuint64(amount, address(token))`. See [call a token from your contract](/fhe-library/confidential-contracts/calling-from-contracts). +The plaintext overload puts the amount in the call data. The encrypted overload keeps it hidden until the claim, but only a contract can call it, because the caller creates the argument with `FHE.shareEuint64(amount, address(token))`. See [call a token from your contract](/cofhe/fhe-library/confidential-contracts/calling-from-contracts). The burn follows the same rule as a transfer: if the amount exceeds the confidential balance, nothing is burned and the claim decrypts to zero. @@ -54,7 +54,7 @@ Each `unshield` opens a claim with a unique ID. The ID is not the burned handle. A claim has five fields: `id`, `to` (the account paid out), `ctHash` (the burned handle), `decryptedAmount` (set when the claim settles), and `claimed`. -Decrypt `ctHash` with [`decryptForTx`](/client-sdk/guides/decrypt-to-tx). No ACP is needed, because the handle is publicly decryptable. Then submit the result: +Decrypt `ctHash` with [`decryptForTx`](/cofhe/client-sdk/guides/decrypt-to-tx). No ACP is needed, because the handle is publicly decryptable. Then submit the result: ```typescript await (await token['unshield(uint64)'](1_000_000n)).wait(); diff --git a/fhe-library/confidential-contracts/fherc20/best-practices.mdx b/cofhe/fhe-library/confidential-contracts/fherc20/best-practices.mdx similarity index 81% rename from fhe-library/confidential-contracts/fherc20/best-practices.mdx rename to cofhe/fhe-library/confidential-contracts/fherc20/best-practices.mdx index 36a27d20..b7a35d96 100644 --- a/fhe-library/confidential-contracts/fherc20/best-practices.mdx +++ b/cofhe/fhe-library/confidential-contracts/fherc20/best-practices.mdx @@ -7,33 +7,33 @@ These are the mistakes that cost the most when you work with FHERC20 tokens. Eac ## Transfers -**Use the amount that moved, not the amount you asked for.** A transfer that exceeds the sender's balance moves zero and does not revert. Every transfer function returns the amount that actually moved, as a `sharedEuint64`. A contract that credits users, settles trades, or counts deposits must work from that returned amount. See [transfers](/fhe-library/confidential-contracts/fherc20/core-features). +**Use the amount that moved, not the amount you asked for.** A transfer that exceeds the sender's balance moves zero and does not revert. Every transfer function returns the amount that actually moved, as a `sharedEuint64`. A contract that credits users, settles trades, or counts deposits must work from that returned amount. See [transfers](/cofhe/fhe-library/confidential-contracts/fherc20/core-features). **Expect a revert from accounts that never held tokens.** A transfer from an account whose balance was never set reverts with `FHERC20ZeroBalance`. That revert is public, so it reveals that the account has never received the token. An account that held tokens and spent them all does not revert. -**Do not read `balanceOf` or `totalSupply` as amounts.** On an FHERC20 token they return an indicator that moves by one tick per transfer, not a balance. Read `confidentialBalanceOf` and decrypt it. The indicator still shows each account's transfer activity, even though it hides the amounts. See [FHERC20 overview](/fhe-library/confidential-contracts/fherc20/overview). +**Do not read `balanceOf` or `totalSupply` as amounts.** On an FHERC20 token they return an indicator that moves by one tick per transfer, not a balance. Read `confidentialBalanceOf` and decrypt it. The indicator still shows each account's transfer activity, even though it hides the amounts. See [FHERC20 overview](/cofhe/fhe-library/confidential-contracts/fherc20/overview). ## Encrypted inputs -**Encrypt with the account that sends the transaction.** An input proof is bound to the account and the consuming contract it was created for. If an operator submits a transfer, the operator's client encrypts the amount, not the holder's. See [encrypting inputs](/client-sdk/guides/encrypting-inputs). +**Encrypt with the account that sends the transaction.** An input proof is bound to the account and the consuming contract it was created for. If an operator submits a transfer, the operator's client encrypts the amount, not the holder's. See [encrypting inputs](/cofhe/client-sdk/guides/encrypting-inputs). **Name the contract that converts the input.** The consuming contract is the one that calls `FHE.asEuint64`. For a direct transfer, that is the token. For a call through your own contract, that is your contract. Anything else fails with `InvalidSigner`. ## Contracts that call the token -**Receive returned values from the token by name.** Read a token's return value with `FHE.receiveEuint64FromCall(result, address(token))`, naming the token you called. See [call a token from your contract](/fhe-library/confidential-contracts/calling-from-contracts). +**Receive returned values from the token by name.** Read a token's return value with `FHE.receiveEuint64FromCall(result, address(token))`, naming the token you called. See [call a token from your contract](/cofhe/fhe-library/confidential-contracts/calling-from-contracts). -**Persist what you keep.** A received handle is usable for the current transaction only. Call `FHE.allowThis` on any value you store, and `FHE.allow` for each account that should decrypt it. See [access control](/fhe-library/core-concepts/access-control). +**Persist what you keep.** A received handle is usable for the current transaction only. Call `FHE.allowThis` on any value you store, and `FHE.allow` for each account that should decrypt it. See [access control](/cofhe/fhe-library/core-concepts/access-control). -**Check who calls your receiver.** `onConfidentialTransferReceived` is an external function, and any contract can call it. Check that `msg.sender` is the token you accept, and receive the amount with `FHE.receiveEuint64Param`. Every confidential transfer is `nonReentrant`, so your callback cannot start another transfer on the same token. See [transfer callbacks](/fhe-library/confidential-contracts/fherc20/transfer-callbacks). +**Check who calls your receiver.** `onConfidentialTransferReceived` is an external function, and any contract can call it. Check that `msg.sender` is the token you accept, and receive the amount with `FHE.receiveEuint64Param`. Every confidential transfer is `nonReentrant`, so your callback cannot start another transfer on the same token. See [transfer callbacks](/cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks). ## Operators -**Keep operator windows short.** An operator can move any amount until its `until` timestamp, because there is no per-amount allowance. Grant the shortest window the flow needs, and revoke with `setOperator(operator, 0)` when it is done. See [operators](/fhe-library/confidential-contracts/fherc20/operators). +**Keep operator windows short.** An operator can move any amount until its `until` timestamp, because there is no per-amount allowance. Grant the shortest window the flow needs, and revoke with `setOperator(operator, 0)` when it is done. See [operators](/cofhe/fhe-library/confidential-contracts/fherc20/operators). ## Wrappers -**Look up claims by ID.** `claimUnshielded` takes the claim ID from `getUserClaims` or `getClaim`. The ciphertext handle is what you decrypt, not what you claim with. See [wrap ERC-20 tokens and ETH](/fhe-library/confidential-contracts/fherc20/fherc20-wrapper). +**Look up claims by ID.** `claimUnshielded` takes the claim ID from `getUserClaims` or `getClaim`. The ciphertext handle is what you decrypt, not what you claim with. See [wrap ERC-20 tokens and ETH](/cofhe/fhe-library/confidential-contracts/fherc20/fherc20-wrapper). **Treat unshielded amounts as public.** Unshielding makes the burned amount publicly decryptable, and the claim publishes it in plaintext. The `uint64` overload of `unshield` also shows it in calldata before that. Only the balances that remain stay confidential. diff --git a/fhe-library/confidential-contracts/fherc20/core-features.mdx b/cofhe/fhe-library/confidential-contracts/fherc20/core-features.mdx similarity index 85% rename from fhe-library/confidential-contracts/fherc20/core-features.mdx rename to cofhe/fhe-library/confidential-contracts/fherc20/core-features.mdx index b1ee57b0..29cc289c 100644 --- a/fhe-library/confidential-contracts/fherc20/core-features.mdx +++ b/cofhe/fhe-library/confidential-contracts/fherc20/core-features.mdx @@ -3,7 +3,7 @@ title: "Transfers and disclosure" description: "Send FHERC20 tokens from a wallet or a contract, read what moved, and make an encrypted amount public" --- -This page covers the FHERC20 transfer functions and the disclosure flow that turns an encrypted amount into a public, verified one. It assumes you know what an [FHERC20 token](/fhe-library/confidential-contracts/fherc20/overview) stores. +This page covers the FHERC20 transfer functions and the disclosure flow that turns an encrypted amount into a public, verified one. It assumes you know what an [FHERC20 token](/cofhe/fhe-library/confidential-contracts/fherc20/overview) stores. ## Which transfer function do you call? @@ -13,12 +13,12 @@ Each transfer comes in two forms. Pick by who holds the amount: | --- | --- | --- | | A wallet | `externalEuint64 encryptedAmount, bytes inputProof` | `confidentialTransfer(address,bytes32,bytes)` | | A contract | `sharedEuint64 sharedAmount` | `confidentialTransfer(address,bytes32)` | -| A wallet, as an [operator](/fhe-library/confidential-contracts/fherc20/operators) | `externalEuint64 encryptedAmount, bytes inputProof` | `confidentialTransferFrom(address,address,bytes32,bytes)` | +| A wallet, as an [operator](/cofhe/fhe-library/confidential-contracts/fherc20/operators) | `externalEuint64 encryptedAmount, bytes inputProof` | `confidentialTransferFrom(address,address,bytes32,bytes)` | | A contract, as an operator | `sharedEuint64 sharedAmount` | `confidentialTransferFrom(address,address,bytes32)` | Both encrypted types are `bytes32` in the ABI, so ethers cannot pick the overload by argument types. Index the contract with the full signature, as in the table. -The `AndCall` versions of both functions also notify the recipient. See [transfer callbacks](/fhe-library/confidential-contracts/fherc20/transfer-callbacks). +The `AndCall` versions of both functions also notify the recipient. See [transfer callbacks](/cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks). ## How do you send from a wallet? @@ -35,7 +35,7 @@ const [amount, inputProof] = await client await token['confidentialTransfer(address,bytes32,bytes)'](recipient, amount, inputProof); ``` -The proof is bound to both the consuming contract and the sender. If either differs, the transaction reverts with `InvalidSigner`. That includes encrypting as one account and submitting from another, so an operator encrypts with its own client. See [encrypting inputs](/client-sdk/guides/encrypting-inputs) for client setup. +The proof is bound to both the consuming contract and the sender. If either differs, the transaction reverts with `InvalidSigner`. That includes encrypting as one account and submitting from another, so an operator encrypts with its own client. See [encrypting inputs](/cofhe/client-sdk/guides/encrypting-inputs) for client setup. ## How do you send from a contract? @@ -46,7 +46,7 @@ sharedEuint64 moved = token.confidentialTransfer(recipient, FHE.shareEuint64(amo euint64 sent = FHE.receiveEuint64FromCall(moved, address(token)); ``` -The `sharedEuint64` overloads accept only a share that the direct caller created for the token. An account that passes a bare handle gets `NotShared`, so a wallet cannot use them. [Call a token from your contract](/fhe-library/confidential-contracts/calling-from-contracts) walks through a full example. +The `sharedEuint64` overloads accept only a share that the direct caller created for the token. An account that passes a bare handle gets `NotShared`, so a wallet cannot use them. [Call a token from your contract](/cofhe/fhe-library/confidential-contracts/calling-from-contracts) walks through a full example. ## What happens when the balance is too low? @@ -73,12 +73,12 @@ All transfer functions are `nonReentrant`. A callback that tries to start a seco | Error | When | | --- | --- | -| FHERC20InvalidReceiver | `to` is the zero address, or a callback recipient reverted without a reason. See [transfer callbacks](/fhe-library/confidential-contracts/fherc20/transfer-callbacks) | +| FHERC20InvalidReceiver | `to` is the zero address, or a callback recipient reverted without a reason. See [transfer callbacks](/cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks) | | FHERC20InvalidSender | `from` is the zero address | | FHERC20ZeroBalance | `from` has never held the token | | FHERC20UnauthorizedSpender | The caller of a `From` function is not an operator for `from` | | FHERC20IncompatibleFunction | The caller used `transfer`, `transferFrom`, `approve`, or `allowance` | -| InvalidSigner | The input proof was signed for a different consuming contract or sender, or a decryption result does not match its handle. See [common errors](/fhe-library/core-concepts/common-errors) | +| InvalidSigner | The input proof was signed for a different consuming contract or sender, or a decryption result does not match its handle. See [common errors](/cofhe/fhe-library/core-concepts/common-errors) | | NotShared | A `sharedEuint64` argument was not shared with the token by the caller | ## How do you make an amount public? @@ -109,6 +109,6 @@ Disclosing a balance handle reveals that balance at that moment and cannot be un ## Related pages -- [Operators](/fhe-library/confidential-contracts/fherc20/operators) -- [Decrypt to transaction](/client-sdk/guides/decrypt-to-tx) -- [Best practices](/fhe-library/confidential-contracts/fherc20/best-practices) +- [Operators](/cofhe/fhe-library/confidential-contracts/fherc20/operators) +- [Decrypt to transaction](/cofhe/client-sdk/guides/decrypt-to-tx) +- [Best practices](/cofhe/fhe-library/confidential-contracts/fherc20/best-practices) diff --git a/fhe-library/confidential-contracts/fherc20/fherc20-wrapper.mdx b/cofhe/fhe-library/confidential-contracts/fherc20/fherc20-wrapper.mdx similarity index 93% rename from fhe-library/confidential-contracts/fherc20/fherc20-wrapper.mdx rename to cofhe/fhe-library/confidential-contracts/fherc20/fherc20-wrapper.mdx index 2246584f..ba2c13cd 100644 --- a/fhe-library/confidential-contracts/fherc20/fherc20-wrapper.mdx +++ b/cofhe/fhe-library/confidential-contracts/fherc20/fherc20-wrapper.mdx @@ -39,7 +39,7 @@ The native wrapper takes the WETH address even if you only use `shieldNative`, b The `6` passed to `FHERC20` does not set the wrapper's decimals. The wrapper overrides `decimals()` with a value derived from the underlying token. The constructor argument only sets the indicator tick, the unit that `balanceOf` reports in. Pass the wrapper's real decimals, which is 6 for any underlying with 6 or more. -Both wrappers call into `ERC20ConfidentialLib`, so you must deploy that library and link it into the wrapper. See [link the shared library](/fhe-library/confidential-contracts/overview#link-the-shared-library) for the steps. +Both wrappers call into `ERC20ConfidentialLib`, so you must deploy that library and link it into the wrapper. See [link the shared library](/cofhe/fhe-library/confidential-contracts/overview#link-the-shared-library) for the steps. Enable the Solidity optimizer for wrappers. With the optimizer off, `ConfidentialETH` compiles to 24,693 bytes and an upgradeable ERC-20 wrapper to 26,751 bytes. Both exceed the 24,576-byte limit and fail to deploy. With `runs: 200` they compile to 14,839 and 15,730 bytes. @@ -123,9 +123,9 @@ There are two `unshield` overloads: | Overload | Caller | Note | | --- | --- | --- | | `unshield(address from, address to, uint64 amount)` | Any account | `amount` is plaintext, so it is visible in the transaction | -| `unshield(address from, address to, sharedEuint64 amount)` | A contract | The caller shares an encrypted amount it holds. See [call a token from your contract](/fhe-library/confidential-contracts/calling-from-contracts) | +| `unshield(address from, address to, sharedEuint64 amount)` | A contract | The caller shares an encrypted amount it holds. See [call a token from your contract](/cofhe/fhe-library/confidential-contracts/calling-from-contracts) | -The caller must be `from` or an [operator](/fhe-library/confidential-contracts/fherc20/operators) for `from`, or the call reverts with `FHERC20UnauthorizedSpender`. `to` cannot be `address(0)`. If the amount exceeds the balance, the wrapper burns zero, and the claim decrypts to `0`. +The caller must be `from` or an [operator](/cofhe/fhe-library/confidential-contracts/fherc20/operators) for `from`, or the call reverts with `FHERC20UnauthorizedSpender`. `to` cannot be `address(0)`. If the amount exceeds the balance, the wrapper burns zero, and the claim decrypts to `0`. ### Find and settle the claim @@ -143,7 +143,7 @@ const { decryptedValue, signature } = await client await eUSDC.claimUnshielded(claim.id, decryptedValue, signature); ``` -Any account can submit the claim. The payout always goes to the claim's `to`, so a relayer can settle claims for your users. `claimUnshieldedBatch(ids, values, signatures)` settles several in one transaction and reverts as a whole if any element is invalid. See [decrypt to transaction](/client-sdk/guides/decrypt-to-tx) for the SDK side. +Any account can submit the claim. The payout always goes to the claim's `to`, so a relayer can settle claims for your users. `claimUnshieldedBatch(ids, values, signatures)` settles several in one transaction and reverts as a whole if any element is invalid. See [decrypt to transaction](/cofhe/client-sdk/guides/decrypt-to-tx) for the SDK side. `getUserClaims` returns only pending claims. `getClaim(id)` returns any claim as this struct: @@ -178,7 +178,7 @@ The ERC-20 wrapper assumes it receives the full amount it pulls. Fee-on-transfer | `ClaimBatchLengthMismatch` | The batch arrays have different lengths | | `InvalidSigner` | The decrypted value or signature does not match the claim's handle | -`InvalidSigner` comes from the TaskManager, which verifies the decryption. See [common errors](/fhe-library/core-concepts/common-errors) for the other TaskManager errors. +`InvalidSigner` comes from the TaskManager, which verifies the decryption. See [common errors](/cofhe/fhe-library/core-concepts/common-errors) for the other TaskManager errors. ## Events diff --git a/fhe-library/confidential-contracts/fherc20/operators.mdx b/cofhe/fhe-library/confidential-contracts/fherc20/operators.mdx similarity index 77% rename from fhe-library/confidential-contracts/fherc20/operators.mdx rename to cofhe/fhe-library/confidential-contracts/fherc20/operators.mdx index 0041665d..c223cd23 100644 --- a/fhe-library/confidential-contracts/fherc20/operators.mdx +++ b/cofhe/fhe-library/confidential-contracts/fherc20/operators.mdx @@ -32,9 +32,9 @@ An operator can move the holder's whole balance, in any number of transfers, unt Operator rights apply to every function that takes a `from` address: -- `confidentialTransferFrom`, in both the wallet and the contract form. See [transfers](/fhe-library/confidential-contracts/fherc20/core-features#which-transfer-function-do-you-call). -- `confidentialTransferFromAndCall`. See [transfer callbacks](/fhe-library/confidential-contracts/fherc20/transfer-callbacks). -- `unshield(from, to, amount)` on the [wrappers](/fhe-library/confidential-contracts/fherc20/fherc20-wrapper), which sends the underlying tokens to any `to`. +- `confidentialTransferFrom`, in both the wallet and the contract form. See [transfers](/cofhe/fhe-library/confidential-contracts/fherc20/core-features#which-transfer-function-do-you-call). +- `confidentialTransferFromAndCall`. See [transfer callbacks](/cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks). +- `unshield(from, to, amount)` on the [wrappers](/cofhe/fhe-library/confidential-contracts/fherc20/fherc20-wrapper), which sends the underlying tokens to any `to`. A caller that is not an operator for `from` gets `FHERC20UnauthorizedSpender(holder, spender)`. @@ -61,9 +61,9 @@ A balance that is too low moves zero, as with any transfer. The operator does no A contract that pulls tokens from users, such as a vault, must be an operator for each user. The user calls `setOperator(vaultAddress, until)` before calling the vault. The vault then calls the `sharedEuint64` form of `confidentialTransferFrom`, and `msg.sender` in the token is the vault. -[Call a token from your contract](/fhe-library/confidential-contracts/calling-from-contracts) has a complete vault that deposits and withdraws this way. +[Call a token from your contract](/cofhe/fhe-library/confidential-contracts/calling-from-contracts) has a complete vault that deposits and withdraws this way. ## Related pages -- [Transfers and disclosure](/fhe-library/confidential-contracts/fherc20/core-features) -- [Best practices](/fhe-library/confidential-contracts/fherc20/best-practices) +- [Transfers and disclosure](/cofhe/fhe-library/confidential-contracts/fherc20/core-features) +- [Best practices](/cofhe/fhe-library/confidential-contracts/fherc20/best-practices) diff --git a/fhe-library/confidential-contracts/fherc20/overview.mdx b/cofhe/fhe-library/confidential-contracts/fherc20/overview.mdx similarity index 82% rename from fhe-library/confidential-contracts/fherc20/overview.mdx rename to cofhe/fhe-library/confidential-contracts/fherc20/overview.mdx index 5e217566..12fadb56 100644 --- a/fhe-library/confidential-contracts/fherc20/overview.mdx +++ b/cofhe/fhe-library/confidential-contracts/fherc20/overview.mdx @@ -5,7 +5,7 @@ description: "How an FHERC20 token stores encrypted balances, what stays public, FHERC20 is a token whose balances exist only as encrypted values. It implements the confidential token interface from [ERC-7984](https://eips.ethereum.org/EIPS/eip-7984) and keeps a read-only ERC-20 surface so wallets and explorers still recognize it. Read this page to build an FHERC20 token and to understand what it reveals. -If your token must also keep working as a normal ERC-20, use [ERC20Confidential](/fhe-library/confidential-contracts/dual-mode/overview) instead. To make an existing ERC-20 or ETH confidential, use a [wrapper](/fhe-library/confidential-contracts/fherc20/fherc20-wrapper). +If your token must also keep working as a normal ERC-20, use [ERC20Confidential](/cofhe/fhe-library/confidential-contracts/dual-mode/overview) instead. To make an existing ERC-20 or ETH confidential, use a [wrapper](/cofhe/fhe-library/confidential-contracts/fherc20/fherc20-wrapper). ## What is encrypted and what is public? @@ -49,7 +49,7 @@ const handle = await token.confidentialBalanceOf(account); const balance = await client.decryptForView(handle, FheTypes.Uint64).execute(); ``` -`decryptForView` signs with an [Access Control Permission](/client-sdk/guides/acps) (ACP) for the connected account. See [decrypt to view](/client-sdk/guides/decrypt-to-view) for setting one up. +`decryptForView` signs with an [Access Control Permission](/cofhe/client-sdk/guides/acps) (ACP) for the connected account. See [decrypt to view](/cofhe/client-sdk/guides/decrypt-to-view) for setting one up. `confidentialBalanceOf` returns a handle, not an amount. A handle you read once goes stale after the next transfer, because every balance change creates a new handle. @@ -90,7 +90,7 @@ contract RewardPoints is FHERC20, Ownable { } ``` -The constructor takes the name, symbol, decimals, and a contract URI ([ERC-7572](https://eips.ethereum.org/EIPS/eip-7572)). Pass an empty string if you have no URI. `FHERC20` does not need [the shared library](/fhe-library/confidential-contracts/overview#link-the-shared-library), so it deploys like any other contract. +The constructor takes the name, symbol, decimals, and a contract URI ([ERC-7572](https://eips.ethereum.org/EIPS/eip-7572)). Pass an empty string if you have no URI. `FHERC20` does not need [the shared library](/cofhe/fhe-library/confidential-contracts/overview#link-the-shared-library), so it deploys like any other contract. A mint function that takes a plaintext `uint64` works too, but the amount is visible in the transaction's calldata. @@ -101,7 +101,7 @@ A mint function that takes a plaintext `uint64` works too, but the amount is vis | Contract | Use it for | | --- | --- | | FHERC20 | A token deployed with a constructor | -| FHERC20Upgradeable | The same token behind a proxy. See [upgradeable tokens](/fhe-library/confidential-contracts/upgradeable) | +| FHERC20Upgradeable | The same token behind a proxy. See [upgradeable tokens](/cofhe/fhe-library/confidential-contracts/upgradeable) | | FHERC20ERC20Wrapper | An FHERC20 backed by an existing ERC-20 | | FHERC20NativeWrapper | An FHERC20 backed by ETH | @@ -109,7 +109,7 @@ A mint function that takes a plaintext `uint64` works too, but the amount is vis ## Next steps -- [Transfers and disclosure](/fhe-library/confidential-contracts/fherc20/core-features): send tokens and make an amount public. -- [Operators](/fhe-library/confidential-contracts/fherc20/operators): let another account move tokens for a holder. -- [Transfer callbacks](/fhe-library/confidential-contracts/fherc20/transfer-callbacks): notify a receiving contract in the same transaction. -- [Best practices](/fhe-library/confidential-contracts/fherc20/best-practices): mistakes that leak amounts or lose funds. +- [Transfers and disclosure](/cofhe/fhe-library/confidential-contracts/fherc20/core-features): send tokens and make an amount public. +- [Operators](/cofhe/fhe-library/confidential-contracts/fherc20/operators): let another account move tokens for a holder. +- [Transfer callbacks](/cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks): notify a receiving contract in the same transaction. +- [Best practices](/cofhe/fhe-library/confidential-contracts/fherc20/best-practices): mistakes that leak amounts or lose funds. diff --git a/fhe-library/confidential-contracts/fherc20/transfer-callbacks.mdx b/cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks.mdx similarity index 88% rename from fhe-library/confidential-contracts/fherc20/transfer-callbacks.mdx rename to cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks.mdx index 21de81d9..202ab16f 100644 --- a/fhe-library/confidential-contracts/fherc20/transfer-callbacks.mdx +++ b/cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks.mdx @@ -11,7 +11,7 @@ A plain transfer to a contract gives the contract tokens but no chance to react. | --- | --- | | `confidentialTransferAndCall(address,bytes32,bytes,bytes)` | A wallet, with `to`, the encrypted amount, `inputProof`, and `data` | | `confidentialTransferAndCall(address,bytes32,bytes)` | A contract, with `to`, a `sharedEuint64`, and `data` | -| `confidentialTransferFromAndCall(address,address,bytes32,bytes,bytes)` | A wallet [operator](/fhe-library/confidential-contracts/fherc20/operators), with `from`, `to`, the encrypted amount, `inputProof`, and `data` | +| `confidentialTransferFromAndCall(address,address,bytes32,bytes,bytes)` | A wallet [operator](/cofhe/fhe-library/confidential-contracts/fherc20/operators), with `from`, `to`, the encrypted amount, `inputProof`, and `data` | | `confidentialTransferFromAndCall(address,address,bytes32,bytes)` | A contract operator, with `from`, `to`, a `sharedEuint64`, and `data` | In the wallet forms, `inputProof` comes right after the encrypted amount and before `data`. Both are `bytes`, so swapping them compiles and fails at runtime. `data` is passed to the recipient unchanged. @@ -113,10 +113,10 @@ Do not move the tokens back yourself and also return false. The token refunds on The refund step runs on every `AndCall`, even when it refunds zero or `to` has no code. Each call therefore emits `Transfer` and `ConfidentialTransfer` twice: once from `from` to `to`, then once from `to` back to `from`. -The two steps also cancel out in the [indicators](/fhe-library/confidential-contracts/fherc20/overview#what-do-the-erc-20-functions-return). A callback transfer leaves both indicators where they were, except that a first-time recipient moves from `0` to `7984.0000`. +The two steps also cancel out in the [indicators](/cofhe/fhe-library/confidential-contracts/fherc20/overview#what-do-the-erc-20-functions-return). A callback transfer leaves both indicators where they were, except that a first-time recipient moves from `0` to `7984.0000`. ## Related pages -- [Call a token from your contract](/fhe-library/confidential-contracts/calling-from-contracts) -- [Transfers and disclosure](/fhe-library/confidential-contracts/fherc20/core-features) -- [Best practices](/fhe-library/confidential-contracts/fherc20/best-practices) +- [Call a token from your contract](/cofhe/fhe-library/confidential-contracts/calling-from-contracts) +- [Transfers and disclosure](/cofhe/fhe-library/confidential-contracts/fherc20/core-features) +- [Best practices](/cofhe/fhe-library/confidential-contracts/fherc20/best-practices) diff --git a/fhe-library/confidential-contracts/overview.mdx b/cofhe/fhe-library/confidential-contracts/overview.mdx similarity index 88% rename from fhe-library/confidential-contracts/overview.mdx rename to cofhe/fhe-library/confidential-contracts/overview.mdx index e9bdf4a8..c31f36cb 100644 --- a/fhe-library/confidential-contracts/overview.mdx +++ b/cofhe/fhe-library/confidential-contracts/overview.mdx @@ -3,7 +3,7 @@ title: "Overview" description: "What the fhenix-confidential-contracts package provides, which token to build on, and how to install and link it" --- -`fhenix-confidential-contracts` is a Solidity package of confidential ERC-20 tokens built on [`FHE.sol`](/fhe-library/reference/fhe-sol/overview). Balances and transfer amounts are stored as encrypted handles (`euint64`), so only the accounts the token grants access to can decrypt them. Read this page to pick a contract, install the package, and deploy a token that needs the shared library. +`fhenix-confidential-contracts` is a Solidity package of confidential ERC-20 tokens built on [`FHE.sol`](/cofhe/fhe-library/reference/fhe-sol/overview). Balances and transfer amounts are stored as encrypted handles (`euint64`), so only the accounts the token grants access to can decrypt them. Read this page to pick a contract, install the package, and deploy a token that needs the shared library. The source is public at [FhenixProtocol/fhenix-confidential-contracts](https://github.com/FhenixProtocol/fhenix-confidential-contracts/tree/v0.4.0/contracts), under the MIT license. These docs cover version `0.4.0`. @@ -36,7 +36,7 @@ Every contract above has an upgradeable variant with the `Upgradeable` suffix, w npm install fhenix-confidential-contracts@0.4.0 ``` -The package depends on `@fhenixprotocol/cofhe-contracts@1.0.0` exactly, plus `@openzeppelin/contracts` and `@openzeppelin/contracts-upgradeable`. Keep your own `cofhe-contracts` pin on the same version, or npm installs two copies of `FHE.sol`. See the [compatibility page](/get-started/introduction/compatibility) for the matching SDK and plugin versions. +The package depends on `@fhenixprotocol/cofhe-contracts@1.0.0` exactly, plus `@openzeppelin/contracts` and `@openzeppelin/contracts-upgradeable`. Keep your own `cofhe-contracts` pin on the same version, or npm installs two copies of `FHE.sol`. See the [compatibility page](/cofhe/get-started/introduction/compatibility) for the matching SDK and plugin versions. Import contracts by their path inside the package: @@ -69,7 +69,7 @@ const [amount, inputProof] = await client await token['confidentialTransfer(address,bytes32,bytes)'](recipient, amount, inputProof); ``` -`externalEuint64` is `bytes32` in the ABI, which is why the signature reads `bytes32`. See [encrypting inputs](/client-sdk/guides/encrypting-inputs) for setting up `client`. +`externalEuint64` is `bytes32` in the ABI, which is why the signature reads `bytes32`. See [encrypting inputs](/cofhe/client-sdk/guides/encrypting-inputs) for setting up `client`. ## Link the shared library @@ -116,21 +116,21 @@ Version `0.4.0` follows the `0.7` CoFHE release and changes every function that - Wrappers and `ERC20Confidential` must be linked to `ERC20ConfidentialLib`. - Claims are keyed by a claim ID, not by the ciphertext handle. Read the ID from `getUserClaims` before you call `claimUnshielded`. -A contract that passed a bare handle still compiles against `0.4.0`, because `sharedEuint64` has the same ABI encoding as `euint64`. It fails at runtime with `NotShared`. The [changelog](https://github.com/FhenixProtocol/fhenix-confidential-contracts/blob/v0.4.0/CHANGELOG.md) lists every change. For the client side, see [migrating to 0.7](/client-sdk/introduction/migrating-to-0-7). +A contract that passed a bare handle still compiles against `0.4.0`, because `sharedEuint64` has the same ABI encoding as `euint64`. It fails at runtime with `NotShared`. The [changelog](https://github.com/FhenixProtocol/fhenix-confidential-contracts/blob/v0.4.0/CHANGELOG.md) lists every change. For the client side, see [migrating to 0.7](/cofhe/client-sdk/introduction/migrating-to-0-7). ## Next steps - + Tokens with encrypted balances only. - + Shield an existing token into a confidential one, and claim it back. - + A public ERC-20 with an encrypted balance next to it. - + Pass encrypted amounts between your contract and a token. diff --git a/fhe-library/confidential-contracts/upgradeable.mdx b/cofhe/fhe-library/confidential-contracts/upgradeable.mdx similarity index 94% rename from fhe-library/confidential-contracts/upgradeable.mdx rename to cofhe/fhe-library/confidential-contracts/upgradeable.mdx index 3982dad7..d80d8aad 100644 --- a/fhe-library/confidential-contracts/upgradeable.mdx +++ b/cofhe/fhe-library/confidential-contracts/upgradeable.mdx @@ -83,7 +83,7 @@ contract DualTokenUpgradeable is ERC20ConfidentialUpgradeable { } ``` -`__ERC20Confidential_init` deploys the token's [indicator token](/fhe-library/confidential-contracts/dual-mode/dual-balance-model), so each proxy gets its own. +`__ERC20Confidential_init` deploys the token's [indicator token](/cofhe/fhe-library/confidential-contracts/dual-mode/dual-balance-model), so each proxy gets its own. ## Deploy and upgrade @@ -108,7 +108,7 @@ const wrapper = await upgrades.deployProxy(Wrapper, [usdcAddress], { unsafeAllow await upgrades.upgradeProxy(await wrapper.getAddress(), Wrapper, { unsafeAllowLinkedLibraries: true }); ``` -Without the flag, the plugin rejects the implementation as not upgrade safe. The flag tells it you have checked the library yourself. `ERC20ConfidentialLib` holds no storage of its own: it runs against the token's storage through `delegatecall`. See [link the shared library](/fhe-library/confidential-contracts/overview#link-the-shared-library) for deploying the library. +Without the flag, the plugin rejects the implementation as not upgrade safe. The flag tells it you have checked the library yourself. `ERC20ConfidentialLib` holds no storage of its own: it runs against the token's storage through `delegatecall`. See [link the shared library](/cofhe/fhe-library/confidential-contracts/overview#link-the-shared-library) for deploying the library. ## Where state lives @@ -131,4 +131,4 @@ An `FHERC20Upgradeable` proxy from `0.3.x` keeps its balances when you upgrade i - **Wrapper proxies with pending claims.** `0.4.0` keys claims by claim ID instead of by handle, in a layout that is not compatible with the `0.3.x` claim store. Claims still pending at upgrade time cannot be settled afterwards. Have users claim, or claim for them, before you upgrade. - **`ERC20ConfidentialUpgradeable` proxies from a pre-release build.** `confidentialTotalSupply()` reads a stored handle that older implementations did not write, and returns a zero handle until something refreshes it. Call `syncConfidentialTotalSupply()` once after the upgrade. Anyone can call it. -Callers also need the `0.4.0` interface after the upgrade. The [confidential contracts overview](/fhe-library/confidential-contracts/overview) lists what changed for callers since `0.3`. +Callers also need the `0.4.0` interface after the upgrade. The [confidential contracts overview](/cofhe/fhe-library/confidential-contracts/overview) lists what changed for callers since `0.3`. diff --git a/fhe-library/core-concepts/access-control.mdx b/cofhe/fhe-library/core-concepts/access-control.mdx similarity index 96% rename from fhe-library/core-concepts/access-control.mdx rename to cofhe/fhe-library/core-concepts/access-control.mdx index 45d7bd0b..77c9b894 100644 --- a/fhe-library/core-concepts/access-control.mdx +++ b/cofhe/fhe-library/core-concepts/access-control.mdx @@ -52,7 +52,7 @@ The ACL governs **operation creation**. Computing on a handle, and requesting it FHE.publishDecryptResult(seenHandle, plaintext, signature); ``` -`publishDecryptResult` (and `verifyDecryptResult`) only check the signature. The TaskManager recovers the signer of an ECDSA signature over that exact `(result, encType, chainId, ctHash)` message, and accepts the result only if the recovered address equals the registered `decryptResultSigner`. That address belongs to [Teecryptor](/deep-dive/cofhe-components/teecryptor). Publication is deliberately permissionless so clients and relayers can settle results onchain. +`publishDecryptResult` (and `verifyDecryptResult`) only check the signature. The TaskManager recovers the signer of an ECDSA signature over that exact `(result, encType, chainId, ctHash)` message, and accepts the result only if the recovered address equals the registered `decryptResultSigner`. That address belongs to [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor). Publication is deliberately permissionless so clients and relayers can settle results onchain. What protects the value is that an attacker cannot *obtain* that signature. Only Teecryptor can produce it. Its signing key never leaves the enclave, so no other party can sign a result the TaskManager will accept. Teecryptor signs only in response to a decryption request, and that request is ACL-gated. The requester must hold permission on the handle and present a valid ACP. The one exception is a handle marked with `FHE.allowPublic()`, which anyone can request. Without permission, Teecryptor denies the request and produces no signature, so there is nothing valid to publish. @@ -116,7 +116,7 @@ FHE.allowTransient(secretValue, otherContract); // Temporary access for this tx Marks a ciphertext handle as eligible for public decryption. Anyone can then request decryption of this value offchain via `decryptForTx` and publish or verify the result onchain. -Use this when a value is intended to become public, for example, the amount burned when you [unshield an FHERC20 token](/fhe-library/confidential-contracts/fherc20/fherc20-wrapper). +Use this when a value is intended to become public, for example, the amount burned when you [unshield an FHERC20 token](/cofhe/fhe-library/confidential-contracts/fherc20/fherc20-wrapper). ```solidity euint32 burnedAmount = FHE.asEuint32(input); @@ -196,7 +196,7 @@ A grant cannot be revoked, and the receiver can pass access on. See [who you tru ## Practical examples -For detailed examples on how to explicitly manage ciphertext allowances in contracts, see the [ACL Usage Examples](/tutorials/acl-usage-examples) guide. +For detailed examples on how to explicitly manage ciphertext allowances in contracts, see the [ACL Usage Examples](/cofhe/tutorials/acl-usage-examples) guide. ### A token transfer diff --git a/fhe-library/core-concepts/common-errors.mdx b/cofhe/fhe-library/core-concepts/common-errors.mdx similarity index 84% rename from fhe-library/core-concepts/common-errors.mdx rename to cofhe/fhe-library/core-concepts/common-errors.mdx index 7698847d..85334016 100644 --- a/fhe-library/core-concepts/common-errors.mdx +++ b/cofhe/fhe-library/core-concepts/common-errors.mdx @@ -11,12 +11,12 @@ This page documents the limits and error messages you are most likely to meet wh Always verify you're using compatible component versions. Many errors can be resolved by ensuring you're using the latest versions of all CoFHE components. - + Encountering cryptic `execution reverted: 0x...` errors? Use the **@fhenixprotocol/cofhe-errors** package to decode them instantly: ```bash npx cofhe-errors 0x118cdaa7 ``` - See the [CoFHE Errors Package](/fhe-library/reference/cofhe-errors) documentation for usage, and the [Error Reference](/fhe-library/reference/cofhe-errors-reference) for the complete list. The package predates the current contracts, so a selector it does not know is not necessarily invalid: check the reference. + See the [CoFHE Errors Package](/cofhe/fhe-library/reference/cofhe-errors) documentation for usage, and the [Error Reference](/cofhe/fhe-library/reference/cofhe-errors-reference) for the complete list. The package predates the current contracts, so a selector it does not know is not necessarily invalid: check the reference. ## Common issues @@ -45,7 +45,7 @@ pnpm list @fhenixprotocol/cofhe-contracts -Check the [Compatibility](/get-started/introduction/compatibility) page to ensure you're using a supported version. +Check the [Compatibility](/cofhe/get-started/introduction/compatibility) page to ensure you're using a supported version. @@ -73,7 +73,7 @@ This section will be expanded over time as new issues arise. If you encounter an ## Possible errors from Solidity -The errors below are the ones a contract can hit during normal development. Each comes with its selector so you can match it against an `execution reverted: 0x...` message. Admin, upgrade, and signature-parsing errors are listed on the [Error Reference](/fhe-library/reference/cofhe-errors-reference) page only. +The errors below are the ones a contract can hit during normal development. Each comes with its selector so you can match it against an `execution reverted: 0x...` message. Admin, upgrade, and signature-parsing errors are listed on the [Error Reference](/cofhe/fhe-library/reference/cofhe-errors-reference) page only. ### Access control @@ -131,7 +131,7 @@ These four errors come from the Access Control Permission (ACP) check in the ACL ### Where to look first -- **Access control errors** almost always mean a missing `FHE.allowThis` or `FHE.allow` in an earlier transaction. See [access control](/fhe-library/core-concepts/access-control). +- **Access control errors** almost always mean a missing `FHE.allowThis` or `FHE.allow` in an earlier transaction. See [access control](/cofhe/fhe-library/core-concepts/access-control). - **Input validation errors** usually mean the encrypted input was produced for a different contract, account, or chain. Re-encrypt with the consuming contract set. - **Type errors** mean the two sides of an operation do not match. Cast with `FHE.asEuintXX` so both operands share a type and zone. - **Decryption errors** mean a result was read before it existed, or the wrong entry point was used. @@ -147,14 +147,14 @@ When encountering errors: 5. **Test in mock environment**: Use the mock environment to debug issues without network delays -Many errors can be prevented by following [best practices](/fhe-library/introduction/best-practices) and ensuring proper access control management. +Many errors can be prevented by following [best practices](/cofhe/fhe-library/introduction/best-practices) and ensuring proper access control management. ## Next steps -- Use the [CoFHE Errors Package](/fhe-library/reference/cofhe-errors) to decode error selectors -- View the complete [Error Reference](/fhe-library/reference/cofhe-errors-reference) -- Review the [Compatibility](/get-started/introduction/compatibility) page for version requirements -- Learn about [access control](/fhe-library/core-concepts/access-control) to prevent authorization errors -- Check [best practices](/fhe-library/introduction/best-practices) for secure FHE development +- Use the [CoFHE Errors Package](/cofhe/fhe-library/reference/cofhe-errors) to decode error selectors +- View the complete [Error Reference](/cofhe/fhe-library/reference/cofhe-errors-reference) +- Review the [Compatibility](/cofhe/get-started/introduction/compatibility) page for version requirements +- Learn about [access control](/cofhe/fhe-library/core-concepts/access-control) to prevent authorization errors +- Check [best practices](/cofhe/fhe-library/introduction/best-practices) for secure FHE development diff --git a/fhe-library/core-concepts/conditions.mdx b/cofhe/fhe-library/core-concepts/conditions.mdx similarity index 97% rename from fhe-library/core-concepts/conditions.mdx rename to cofhe/fhe-library/core-concepts/conditions.mdx index ff6b5d8e..a26e103c 100644 --- a/fhe-library/core-concepts/conditions.mdx +++ b/cofhe/fhe-library/core-concepts/conditions.mdx @@ -240,5 +240,5 @@ In the example above, the actual bid amounts remain encrypted throughout the auc ## Related Topics -- Learn more about comparison operations in [FHE Encrypted Operations](/fhe-library/core-concepts/encrypted-operations) -- Understand how to manage access in [Access Control](/fhe-library/core-concepts/access-control) +- Learn more about comparison operations in [FHE Encrypted Operations](/cofhe/fhe-library/core-concepts/encrypted-operations) +- Understand how to manage access in [Access Control](/cofhe/fhe-library/core-concepts/access-control) diff --git a/fhe-library/core-concepts/data-evaluation.mdx b/cofhe/fhe-library/core-concepts/data-evaluation.mdx similarity index 96% rename from fhe-library/core-concepts/data-evaluation.mdx rename to cofhe/fhe-library/core-concepts/data-evaluation.mdx index f71710bf..c9cf03bc 100644 --- a/fhe-library/core-concepts/data-evaluation.mdx +++ b/cofhe/fhe-library/core-concepts/data-evaluation.mdx @@ -25,7 +25,7 @@ This line emits one `TaskCreated` event describing a subtraction over two operan euint8 res = FHE.asEuint8(42); ``` -This emits a task saying "create a trivially encrypted ciphertext for the plaintext `42`". See [trivial encryption](/fhe-library/core-concepts/trivial-encryption) for when this is safe to use. +This emits a task saying "create a trivially encrypted ciphertext for the plaintext `42`". See [trivial encryption](/cofhe/fhe-library/core-concepts/trivial-encryption) for when this is safe to use. **Adding encrypted values:** @@ -70,7 +70,7 @@ ebool isBigger = FHE.gt(newBid, currentBid); `FHE.sol` submits a task meaning "compare the ciphertexts behind `0xab12...` and `0xcd34...`". The handle of the result lands in `isBigger`, typed `ebool`. -Wondering what to do with `ebool isBigger`? Read [conditionals](/fhe-library/core-concepts/conditions). You cannot branch on it with `if`. +Wondering what to do with `ebool isBigger`? Read [conditionals](/cofhe/fhe-library/core-concepts/conditions). You cannot branch on it with `if`. ### Working with a raw handle diff --git a/fhe-library/core-concepts/decryption-operations.mdx b/cofhe/fhe-library/core-concepts/decryption-operations.mdx similarity index 94% rename from fhe-library/core-concepts/decryption-operations.mdx rename to cofhe/fhe-library/core-concepts/decryption-operations.mdx index 8bf0391e..5096422a 100644 --- a/fhe-library/core-concepts/decryption-operations.mdx +++ b/cofhe/fhe-library/core-concepts/decryption-operations.mdx @@ -9,11 +9,11 @@ Decryption is the process of converting encrypted data back into its original fo Decryption in CoFHE is a multi-step process that involves both offchain and onchain components: -1. A client requests decryption offchain and receives the plaintext along with a signature from [Teecryptor](/deep-dive/cofhe-components/teecryptor). +1. A client requests decryption offchain and receives the plaintext along with a signature from [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor). 2. The plaintext and signature are submitted onchain, where the contract publishes or verifies the result. -Learn more about how CoFHE decrypts in the [Teecryptor](/deep-dive/cofhe-components/teecryptor) guide. +Learn more about how CoFHE decrypts in the [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) guide. --- @@ -81,7 +81,7 @@ function closeBidding() external onlyAuctioneer { ``` -See [Access Control](/fhe-library/core-concepts/access-control) for the full list of permission methods, including `FHE.allowPublic()`. +See [Access Control](/cofhe/fhe-library/core-concepts/access-control) for the full list of permission methods, including `FHE.allowPublic()`. ### Step 2: Request decryption offchain (client-side) @@ -285,7 +285,7 @@ When a value is intended to become public (e.g. unshielding, auction reveals), u -Ensure only authorized parties can request decryption. Use `FHE.allow()` or `FHE.allowSender()` for restricted access. See [Access Control](/fhe-library/core-concepts/access-control). +Ensure only authorized parties can request decryption. Use `FHE.allow()` or `FHE.allowSender()` for restricted access. See [Access Control](/cofhe/fhe-library/core-concepts/access-control). @@ -310,6 +310,6 @@ If you only need to display a value in your UI and don't need an onchain-verifia ## Related Topics -- Learn about access control requirements in [Access Control](/fhe-library/core-concepts/access-control) -- Understand asynchronous operations in [Data Evaluation](/fhe-library/core-concepts/data-evaluation) -- Explore the decryption request flow in [Decryption Request Flow](/deep-dive/data-flows/decryption-request-flow) +- Learn about access control requirements in [Access Control](/cofhe/fhe-library/core-concepts/access-control) +- Understand asynchronous operations in [Data Evaluation](/cofhe/fhe-library/core-concepts/data-evaluation) +- Explore the decryption request flow in [Decryption Request Flow](/cofhe/deep-dive/data-flows/decryption-request-flow) diff --git a/fhe-library/core-concepts/encrypted-operations.mdx b/cofhe/fhe-library/core-concepts/encrypted-operations.mdx similarity index 96% rename from fhe-library/core-concepts/encrypted-operations.mdx rename to cofhe/fhe-library/core-concepts/encrypted-operations.mdx index 44a560c2..3860aedd 100644 --- a/fhe-library/core-concepts/encrypted-operations.mdx +++ b/cofhe/fhe-library/core-concepts/encrypted-operations.mdx @@ -63,7 +63,7 @@ In the back-end, encrypted integers are FHE ciphertexts. The library abstracts a -Each family records where a value came from. A **compute** type is yours, held in storage or produced by an operation. An **input** type arrived from a user offchain and travels with a `bytes` proof that authenticates it. A **shared** type was handed over by another contract during this transaction. See [inputs](/fhe-library/core-concepts/inputs) for how to convert between them. +Each family records where a value came from. A **compute** type is yours, held in storage or produced by an operation. An **input** type arrived from a user offchain and travels with a `bytes` proof that authenticates it. A **shared** type was handed over by another contract during this transaction. See [inputs](/cofhe/fhe-library/core-concepts/inputs) for how to convert between them. The `ebool` type is not a real boolean type. It is implemented as a `euint8` for compatibility with FHE operations. @@ -100,7 +100,7 @@ In this example, `lhs.add(rhs)` performs the addition using the library function ## Supported Operations -Complete documentation of every function in FHE.sol (including inputs and outputs) can be found in the [FHE.sol reference](/fhe-library/reference/fhe-sol/overview). +Complete documentation of every function in FHE.sol (including inputs and outputs) can be found in the [FHE.sol reference](/cofhe/fhe-library/reference/fhe-sol/overview). All operations supported by FHE.sol are listed in the table below. Note that all functions are supported in both direct function calls and library bindings. @@ -177,5 +177,5 @@ euint32 result = FHE.select(condition, valueIfTrue, valueIfFalse); ``` -Learn more about using encrypted conditionals in the [Select vs If-Else](/fhe-library/core-concepts/conditions) guide. +Learn more about using encrypted conditionals in the [Select vs If-Else](/cofhe/fhe-library/core-concepts/conditions) guide. diff --git a/fhe-library/core-concepts/gas-and-benchmarks.mdx b/cofhe/fhe-library/core-concepts/gas-and-benchmarks.mdx similarity index 65% rename from fhe-library/core-concepts/gas-and-benchmarks.mdx rename to cofhe/fhe-library/core-concepts/gas-and-benchmarks.mdx index 048ffa99..a5e6605a 100644 --- a/fhe-library/core-concepts/gas-and-benchmarks.mdx +++ b/cofhe/fhe-library/core-concepts/gas-and-benchmarks.mdx @@ -3,11 +3,11 @@ title: "Gas Costs and Benchmarks" description: "The gas an FHE operation and a confidential transfer take, and where to find operation latency benchmarks" --- -An FHE operation costs gas onchain to request it. The encrypted math itself runs offchain in the [compute pipeline](/deep-dive/cofhe-components/compute-pipeline) and costs no gas. +An FHE operation costs gas onchain to request it. The encrypted math itself runs offchain in the [compute pipeline](/cofhe/deep-dive/cofhe-components/compute-pipeline) and costs no gas. ## Gas per confidential transfer -Whole transactions on the reference [FHERC20](/fhe-library/confidential-contracts/fherc20/overview) token, with an encrypted input amount where the call takes one: +Whole transactions on the reference [FHERC20](/cofhe/fhe-library/confidential-contracts/fherc20/overview) token, with an encrypted input amount where the call takes one: | Action | Gas | |---|---| @@ -18,7 +18,7 @@ Whole transactions on the reference [FHERC20](/fhe-library/confidential-contract ## Gas per operation -The [gas per operation reference](/fhe-library/reference/gas-costs) lists the expected gas of every `FHE.sol` operation. Most operations take 40,000 to 55,000 gas as the first FHE call in a transaction, and about 20,000 less as a later call. +The [gas per operation reference](/cofhe/fhe-library/reference/gas-costs) lists the expected gas of every `FHE.sol` operation. Most operations take 40,000 to 55,000 gas as the first FHE call in a transaction, and about 20,000 less as a later call. ## Performance benchmarks diff --git a/fhe-library/core-concepts/handles.mdx b/cofhe/fhe-library/core-concepts/handles.mdx similarity index 87% rename from fhe-library/core-concepts/handles.mdx rename to cofhe/fhe-library/core-concepts/handles.mdx index c0f9a845..9640ffc1 100644 --- a/fhe-library/core-concepts/handles.mdx +++ b/cofhe/fhe-library/core-concepts/handles.mdx @@ -23,14 +23,14 @@ Both are `internal pure`. They perform no cryptography, make no call to the Task There is one `unwrap` for every encrypted type, and one `wrap` per type because the return type has to differ: `wrapEbool`, `wrapEuint8`, `wrapEuint16`, `wrapEuint32`, `wrapEuint64`, `wrapEuint128`, and `wrapEaddress`. -The bindings give you the same thing in dot form, so `myValue.unwrap()` reads better inside an expression. See [bindings](/fhe-library/reference/fhe-sol/bindings). +The bindings give you the same thing in dot form, so `myValue.unwrap()` reads better inside an expression. See [bindings](/cofhe/fhe-library/reference/fhe-sol/bindings). ## Wrapping does not grant permission **Wrapping a handle grants you nothing.** -The type records what kind of value this is. The [ACL](/fhe-library/core-concepts/access-control) decides whether you may use it. Those are separate systems, and `wrap` only touches the first one. +The type records what kind of value this is. The [ACL](/cofhe/fhe-library/core-concepts/access-control) decides whether you may use it. Those are separate systems, and `wrap` only touches the first one. You can wrap any 32 bytes you like. Nothing reverts, because nothing is checked: @@ -104,7 +104,7 @@ Use a type that carries provenance instead. There is one for every way a value c Each conversion authenticates the value as part of converting it, which is exactly what wrapping a raw handle skips. The two `receive` forms are not interchangeable: pick by how the value arrived, because naming the wrong party silently weakens the check rather than failing. -All of these are covered in [inputs](/fhe-library/core-concepts/inputs). +All of these are covered in [inputs](/cofhe/fhe-library/core-concepts/inputs). ## Checking a handle is real @@ -120,6 +120,6 @@ It does not tell you the handle refers to a ciphertext that exists, or that you ## Related -- [Inputs](/fhe-library/core-concepts/inputs): how values arrive from users and from other contracts. -- [Access control](/fhe-library/core-concepts/access-control): what the ACL permits, and how to grant it. -- [Utility functions](/fhe-library/reference/fhe-sol/utility): the reference entries for `unwrap`, `wrap`, and `isInitialized`. +- [Inputs](/cofhe/fhe-library/core-concepts/inputs): how values arrive from users and from other contracts. +- [Access control](/cofhe/fhe-library/core-concepts/access-control): what the ACL permits, and how to grant it. +- [Utility functions](/cofhe/fhe-library/reference/fhe-sol/utility): the reference entries for `unwrap`, `wrap`, and `isInitialized`. diff --git a/fhe-library/core-concepts/inputs.mdx b/cofhe/fhe-library/core-concepts/inputs.mdx similarity index 93% rename from fhe-library/core-concepts/inputs.mdx rename to cofhe/fhe-library/core-concepts/inputs.mdx index 6c4fb5a6..ef75eef9 100644 --- a/fhe-library/core-concepts/inputs.mdx +++ b/cofhe/fhe-library/core-concepts/inputs.mdx @@ -23,7 +23,7 @@ Notice in the example above the distinction between **`externalEuint32`** and ** ## Input Types Conversion -The **input types** `externalEuintXX` (and `externalEbool`, `externalEaddress`) represent **user input**. Each one is a ciphertext handle that travels with a separate `bytes` proof, and the pair is what lets the contract authenticate the value. For more on that, read about the [ZK-Verifier](/deep-dive/cofhe-components/zk-verifier). +The **input types** `externalEuintXX` (and `externalEbool`, `externalEaddress`) represent **user input**. Each one is a ciphertext handle that travels with a separate `bytes` proof, and the pair is what lets the contract authenticate the value. For more on that, read about the [ZK-Verifier](/cofhe/deep-dive/cofhe-components/zk-verifier). Before you can use an encrypted input, convert it to a regular **encrypted type**, passing the proof alongside the handle: @@ -44,7 +44,7 @@ toBalance = FHE.sub(toBalance, amount); ``` -Read more about the available FHE types and operations in the [FHE Encrypted Operations](/fhe-library/core-concepts/encrypted-operations) guide. +Read more about the available FHE types and operations in the [FHE Encrypted Operations](/cofhe/fhe-library/core-concepts/encrypted-operations) guide. ## Full Example @@ -68,7 +68,7 @@ function transfer( ``` -For the example above to work correctly, you will also need to manage access to the newly created ciphertexts in the `_updateBalance()` function. Learn more about access control in the [ACL Mechanism](/fhe-library/core-concepts/access-control) guide. +For the example above to work correctly, you will also need to manage access to the newly created ciphertexts in the `_updateBalance()` function. Learn more about access control in the [ACL Mechanism](/cofhe/fhe-library/core-concepts/access-control) guide. ## Passing encrypted values between contracts @@ -102,7 +102,7 @@ For `receiveEuintXXFromCall`, `callee` must be the address called in that same e A share is single-use and lasts one transaction, so it cannot be stored, replayed, or rebuilt from an event. To keep a received value, call `FHE.allowThis` on the unwrapped `euintXX`. Expect `NotShared` when nothing was shared with you, `UnexpectedSharer` when the share came from someone other than the party you named, and `SenderNotAllowed` when the sharer does not hold the handle. -The old spelling, an `FHE.allowTransient` grant plus a bare `euintXX` parameter, still compiles and still runs. The compiler will not find these for you, so they have to be found by search. See [migrating to 0.7](/client-sdk/introduction/migrating-to-0-7) for the full pass. +The old spelling, an `FHE.allowTransient` grant plus a bare `euintXX` parameter, still compiles and still runs. The compiler will not find these for you, so they have to be found by search. See [migrating to 0.7](/cofhe/client-sdk/introduction/migrating-to-0-7) for the full pass. ## Additional Examples diff --git a/fhe-library/core-concepts/randomness.mdx b/cofhe/fhe-library/core-concepts/randomness.mdx similarity index 100% rename from fhe-library/core-concepts/randomness.mdx rename to cofhe/fhe-library/core-concepts/randomness.mdx diff --git a/fhe-library/core-concepts/require.mdx b/cofhe/fhe-library/core-concepts/require.mdx similarity index 78% rename from fhe-library/core-concepts/require.mdx rename to cofhe/fhe-library/core-concepts/require.mdx index 1b994c1d..5235c561 100644 --- a/fhe-library/core-concepts/require.mdx +++ b/cofhe/fhe-library/core-concepts/require.mdx @@ -5,7 +5,7 @@ description: "Understanding require statements with encrypted data in FHE" ## Overview -The `require` statement in FHE contracts works similarly to [Conditions (if .. else)](/fhe-library/core-concepts/conditions) because both involve conditional logic on encrypted data. Just like you can't use traditional `if...else` statements with encrypted values, you also can't use standard `require` statements that depend on encrypted conditions. +The `require` statement in FHE contracts works similarly to [Conditions (if .. else)](/cofhe/fhe-library/core-concepts/conditions) because both involve conditional logic on encrypted data. Just like you can't use traditional `if...else` statements with encrypted values, you also can't use standard `require` statements that depend on encrypted conditions. Traditional `require` statements that check encrypted conditions will leak information about your encrypted values through execution paths. @@ -33,7 +33,7 @@ If a transaction reverts based on an encrypted condition, observers can infer in Instead of using `require` with encrypted conditions, you should: -1. **Use `FHE.select`** to handle the conditional logic (see [Conditions (if .. else)](/fhe-library/core-concepts/conditions)) +1. **Use `FHE.select`** to handle the conditional logic (see [Conditions (if .. else)](/cofhe/fhe-library/core-concepts/conditions)) 2. **Only use `require` for non-encrypted conditions** like access control checks, address validation, or other plaintext values ```solidity @@ -52,4 +52,4 @@ euint32 result = FHE.select(encryptedCondition, valueA, valueB); ## Learn More -For detailed guidance on handling conditional logic with encrypted data, see the [Conditions (if .. else)](/fhe-library/core-concepts/conditions) page. +For detailed guidance on handling conditional logic with encrypted data, see the [Conditions (if .. else)](/cofhe/fhe-library/core-concepts/conditions) page. diff --git a/fhe-library/core-concepts/trivial-encryption.mdx b/cofhe/fhe-library/core-concepts/trivial-encryption.mdx similarity index 96% rename from fhe-library/core-concepts/trivial-encryption.mdx rename to cofhe/fhe-library/core-concepts/trivial-encryption.mdx index f18e74e8..aaa71bf3 100644 --- a/fhe-library/core-concepts/trivial-encryption.mdx +++ b/cofhe/fhe-library/core-concepts/trivial-encryption.mdx @@ -21,7 +21,7 @@ euint16 encrypted_number = FHE.asEuint16(number); This is a crucial concept to understand when developing confidential contracts. Any value that is trivially encrypted (e.g. `encrypted_number`) should be treated as public information, even though it uses the same data type as truly encrypted values. -`euints` are only confidential when they are formed from encrypted `inEuint` inputs, which are encrypted offchain. Learn more in the [Data Evaluation](/fhe-library/core-concepts/data-evaluation) guide. +`euints` are only confidential when they are formed from encrypted `inEuint` inputs, which are encrypted offchain. Learn more in the [Data Evaluation](/cofhe/fhe-library/core-concepts/data-evaluation) guide. When two trivially-encrypted numbers are combined in an FHE operation, the result is still not confidential, because an observer can keep track of the calculations. diff --git a/fhe-library/examples/auction-example.mdx b/cofhe/fhe-library/examples/auction-example.mdx similarity index 96% rename from fhe-library/examples/auction-example.mdx rename to cofhe/fhe-library/examples/auction-example.mdx index b83524f7..0a30b6cf 100644 --- a/fhe-library/examples/auction-example.mdx +++ b/cofhe/fhe-library/examples/auction-example.mdx @@ -37,7 +37,7 @@ The auctioneer closes the auction and calls `FHE.allowPublic` on the highest bid -Anyone can call `decryptForTx` offchain to obtain the plaintext values and their signatures from [Teecryptor](/deep-dive/cofhe-components/teecryptor). +Anyone can call `decryptForTx` offchain to obtain the plaintext values and their signatures from [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor). @@ -381,6 +381,6 @@ Decryption happens offchain via `decryptForTx`, and results are verified onchain ## Related Examples -- Learn about conditional logic in [Conditions](/fhe-library/core-concepts/conditions) -- Understand decryption methods in [Decryption Operations](/fhe-library/core-concepts/decryption-operations) -- Explore access control in [Access Control](/fhe-library/core-concepts/access-control) +- Learn about conditional logic in [Conditions](/cofhe/fhe-library/core-concepts/conditions) +- Understand decryption methods in [Decryption Operations](/cofhe/fhe-library/core-concepts/decryption-operations) +- Explore access control in [Access Control](/cofhe/fhe-library/core-concepts/access-control) diff --git a/fhe-library/introduction/best-practices.mdx b/cofhe/fhe-library/introduction/best-practices.mdx similarity index 95% rename from fhe-library/introduction/best-practices.mdx rename to cofhe/fhe-library/introduction/best-practices.mdx index 2cb6bd11..ccf5cae0 100644 --- a/fhe-library/introduction/best-practices.mdx +++ b/cofhe/fhe-library/introduction/best-practices.mdx @@ -11,7 +11,7 @@ This guide outlines key best practices for developing with CoFHE, based on recom Before reading this guide, you should: -- Have completed the [Quick Start](/fhe-library/introduction/quick-start) setup +- Have completed the [Quick Start](/cofhe/fhe-library/introduction/quick-start) setup - Understand basic FHE concepts and encrypted types - Be familiar with Solidity smart contract development @@ -202,8 +202,8 @@ By following these best practices, you'll create more secure, efficient, and mai ## Next Steps -- Learn about [encrypted data types](/fhe-library) and their use cases -- Explore [FHE operations](/fhe-library) available in the library -- Review [access control mechanisms](/fhe-library) for managing permissions -- Check out [common pitfalls](/fhe-library) to avoid +- Learn about [encrypted data types](/cofhe/fhe-library) and their use cases +- Explore [FHE operations](/cofhe/fhe-library) available in the library +- Review [access control mechanisms](/cofhe/fhe-library) for managing permissions +- Check out [common pitfalls](/cofhe/fhe-library) to avoid diff --git a/fhe-library/introduction/overview.mdx b/cofhe/fhe-library/introduction/overview.mdx similarity index 98% rename from fhe-library/introduction/overview.mdx rename to cofhe/fhe-library/introduction/overview.mdx index 27a89995..6f55c369 100644 --- a/fhe-library/introduction/overview.mdx +++ b/cofhe/fhe-library/introduction/overview.mdx @@ -46,7 +46,7 @@ The library supports multiple encrypted data types, each representing an encrypt Each is a `bytes32` handle rather than a struct. It arrives with a separate `bytes` proof, and `FHE.asEuintXX(handle, proof)` converts the pair. -- **Type-specific shared types:** `sharedEuint8` through `sharedEaddress`, for encrypted values handed from one contract to another. See [inputs](/fhe-library/core-concepts/inputs). +- **Type-specific shared types:** `sharedEuint8` through `sharedEaddress`, for encrypted values handed from one contract to another. See [inputs](/cofhe/fhe-library/core-concepts/inputs). --- diff --git a/fhe-library/introduction/quick-start.mdx b/cofhe/fhe-library/introduction/quick-start.mdx similarity index 94% rename from fhe-library/introduction/quick-start.mdx rename to cofhe/fhe-library/introduction/quick-start.mdx index f92fc147..2fe4769c 100644 --- a/fhe-library/introduction/quick-start.mdx +++ b/cofhe/fhe-library/introduction/quick-start.mdx @@ -211,7 +211,7 @@ pnpm base-sepolia:deploy-counter ``` -The plugin ships presets for the first two networks. Base Sepolia has none, so the starter defines that network in its own `hardhat.config.ts`; the [compatibility page](/get-started/introduction/compatibility#supported-networks) shows the block to copy into your own project. +The plugin ships presets for the first two networks. Base Sepolia has none, so the starter defines that network in its own `hardhat.config.ts`; the [compatibility page](/cofhe/get-started/introduction/compatibility#supported-networks) shows the block to copy into your own project. @@ -250,7 +250,7 @@ The JavaScript library for working with FHE contracts: - **Encrypt/Decrypt**: Encrypt data to send to contracts and decrypt results - **Querying**: Fetch encrypted values from FHE contracts -- **Authentication**: Uses [Access Control Permissions](/client-sdk/guides/acps) (ACPs) to authenticate connected users when requesting confidential data +- **Authentication**: Uses [Access Control Permissions](/cofhe/client-sdk/guides/acps) (ACPs) to authenticate connected users when requesting confidential data ### cofhe-mock-contracts @@ -336,14 +336,14 @@ Be aware that FHE operations cost more gas than standard operations. Mock enviro Now that you have your development environment set up, you can: -- Explore the [FHE Library documentation](/fhe-library) to learn about encrypted data types and operations +- Explore the [FHE Library documentation](/cofhe/fhe-library) to learn about encrypted data types and operations - Review the [Counter contract example](https://github.com/FhenixProtocol/cofhe-hardhat-starter/blob/main/contracts/Counter.sol) to see FHE in action -- Check out the [Client SDK documentation](/client-sdk/introduction/overview) for client-side integration -- Learn about [access control mechanisms](/fhe-library) for managing encrypted data permissions +- Check out the [Client SDK documentation](/cofhe/client-sdk/introduction/overview) for client-side integration +- Learn about [access control mechanisms](/cofhe/fhe-library) for managing encrypted data permissions ## Resources -- [Fhenix documentation](/) +- [Fhenix documentation](/cofhe) - [Client SDK GitHub](https://github.com/FhenixProtocol/cofhesdk) - [CoFHE Contracts GitHub](https://github.com/FhenixProtocol/cofhe-contracts) - [cofhe-hardhat-starter GitHub](https://github.com/fhenixprotocol/cofhe-hardhat-starter) diff --git a/fhe-library/reference/cofhe-errors-reference.mdx b/cofhe/fhe-library/reference/cofhe-errors-reference.mdx similarity index 99% rename from fhe-library/reference/cofhe-errors-reference.mdx rename to cofhe/fhe-library/reference/cofhe-errors-reference.mdx index 6ab20fa4..b521a246 100644 --- a/fhe-library/reference/cofhe-errors-reference.mdx +++ b/cofhe/fhe-library/reference/cofhe-errors-reference.mdx @@ -8,7 +8,7 @@ This page lists every custom error the CoFHE host-chain contracts (TaskManager, The list is generated from the contract sources as deployed on the public testnets, checked against Sepolia on 2026-09-01, and from `@fhenixprotocol/cofhe-contracts` 0.2.0. -The `@fhenixprotocol/cofhe-errors` package (1.0.2) predates these contracts. It cannot decode errors added since, such as `NotOnAccessList` or `NotShared`, and it still lists `OnlyAggregatorAllowed`, which the TaskManager no longer raises. Treat this page as the source of truth and see the [package page](/fhe-library/reference/cofhe-errors) for what it does cover. +The `@fhenixprotocol/cofhe-errors` package (1.0.2) predates these contracts. It cannot decode errors added since, such as `NotOnAccessList` or `NotShared`, and it still lists `OnlyAggregatorAllowed`, which the TaskManager no longer raises. Treat this page as the source of truth and see the [package page](/cofhe/fhe-library/reference/cofhe-errors) for what it does cover. ## Errors by contract diff --git a/fhe-library/reference/cofhe-errors.mdx b/cofhe/fhe-library/reference/cofhe-errors.mdx similarity index 92% rename from fhe-library/reference/cofhe-errors.mdx rename to cofhe/fhe-library/reference/cofhe-errors.mdx index d3640e45..83af160f 100644 --- a/fhe-library/reference/cofhe-errors.mdx +++ b/cofhe/fhe-library/reference/cofhe-errors.mdx @@ -24,7 +24,7 @@ You only get a 4-byte error selector (`0x118cdaa7` here) with no readable messag -Version 1.0.2 of the package was published in January 2026 and predates the current contracts. Its database does not include errors added since, such as `NotOnAccessList`, `DecryptFunctionNotSupported`, `LengthMismatch`, `NotShared`, `UnexpectedSharer`, and the ACPShareRegistry errors. It still lists `OnlyAggregatorAllowed`, which the TaskManager no longer raises. When the CLI reports `Error not found for selector`, look the selector up on the [error reference](/fhe-library/reference/cofhe-errors-reference), which is generated from the deployed contracts. +Version 1.0.2 of the package was published in January 2026 and predates the current contracts. Its database does not include errors added since, such as `NotOnAccessList`, `DecryptFunctionNotSupported`, `LengthMismatch`, `NotShared`, `UnexpectedSharer`, and the ACPShareRegistry errors. It still lists `OnlyAggregatorAllowed`, which the TaskManager no longer raises. When the CLI reports `Error not found for selector`, look the selector up on the [error reference](/cofhe/fhe-library/reference/cofhe-errors-reference), which is generated from the deployed contracts. ## Quick start @@ -212,6 +212,6 @@ Becomes: ## Next steps -- View the [error reference](/fhe-library/reference/cofhe-errors-reference), generated from the deployed contracts -- Learn about [common errors](/fhe-library/core-concepts/common-errors) and troubleshooting -- Review [best practices](/fhe-library/introduction/best-practices) for FHE development +- View the [error reference](/cofhe/fhe-library/reference/cofhe-errors-reference), generated from the deployed contracts +- Learn about [common errors](/cofhe/fhe-library/core-concepts/common-errors) and troubleshooting +- Review [best practices](/cofhe/fhe-library/introduction/best-practices) for FHE development diff --git a/fhe-library/reference/fhe-sol/access-control.mdx b/cofhe/fhe-library/reference/fhe-sol/access-control.mdx similarity index 100% rename from fhe-library/reference/fhe-sol/access-control.mdx rename to cofhe/fhe-library/reference/fhe-sol/access-control.mdx diff --git a/fhe-library/reference/fhe-sol/arithmetic.mdx b/cofhe/fhe-library/reference/fhe-sol/arithmetic.mdx similarity index 100% rename from fhe-library/reference/fhe-sol/arithmetic.mdx rename to cofhe/fhe-library/reference/fhe-sol/arithmetic.mdx diff --git a/fhe-library/reference/fhe-sol/bindings.mdx b/cofhe/fhe-library/reference/fhe-sol/bindings.mdx similarity index 100% rename from fhe-library/reference/fhe-sol/bindings.mdx rename to cofhe/fhe-library/reference/fhe-sol/bindings.mdx diff --git a/fhe-library/reference/fhe-sol/bitwise.mdx b/cofhe/fhe-library/reference/fhe-sol/bitwise.mdx similarity index 100% rename from fhe-library/reference/fhe-sol/bitwise.mdx rename to cofhe/fhe-library/reference/fhe-sol/bitwise.mdx diff --git a/fhe-library/reference/fhe-sol/comparison.mdx b/cofhe/fhe-library/reference/fhe-sol/comparison.mdx similarity index 100% rename from fhe-library/reference/fhe-sol/comparison.mdx rename to cofhe/fhe-library/reference/fhe-sol/comparison.mdx diff --git a/fhe-library/reference/fhe-sol/decryption.mdx b/cofhe/fhe-library/reference/fhe-sol/decryption.mdx similarity index 96% rename from fhe-library/reference/fhe-sol/decryption.mdx rename to cofhe/fhe-library/reference/fhe-sol/decryption.mdx index 98d784a0..f55c2d12 100644 --- a/fhe-library/reference/fhe-sol/decryption.mdx +++ b/cofhe/fhe-library/reference/fhe-sol/decryption.mdx @@ -15,7 +15,7 @@ Decryption in CoFHE is a two-phase process: ### publishDecryptResult -Publishes a decrypted result onchain by verifying the signature from [Teecryptor](/deep-dive/cofhe-components/teecryptor). The plaintext is stored and can be read via `getDecryptResultSafe`. +Publishes a decrypted result onchain by verifying the signature from [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor). The plaintext is stored and can be read via `getDecryptResultSafe`. Ciphertext handle diff --git a/fhe-library/reference/fhe-sol/overview.mdx b/cofhe/fhe-library/reference/fhe-sol/overview.mdx similarity index 97% rename from fhe-library/reference/fhe-sol/overview.mdx rename to cofhe/fhe-library/reference/fhe-sol/overview.mdx index ff14adaa..068c1d4e 100644 --- a/fhe-library/reference/fhe-sol/overview.mdx +++ b/cofhe/fhe-library/reference/fhe-sol/overview.mdx @@ -55,7 +55,7 @@ A value handed over by another contract arrives as a shared type instead. `FHE.s | `sharedEuint128` | `euint128` | | `sharedEaddress` | `eaddress` | -See [inputs](/fhe-library/core-concepts/inputs) for when to use each. +See [inputs](/cofhe/fhe-library/core-concepts/inputs) for when to use each. ## Security Considerations diff --git a/fhe-library/reference/fhe-sol/type-conversion.mdx b/cofhe/fhe-library/reference/fhe-sol/type-conversion.mdx similarity index 100% rename from fhe-library/reference/fhe-sol/type-conversion.mdx rename to cofhe/fhe-library/reference/fhe-sol/type-conversion.mdx diff --git a/fhe-library/reference/fhe-sol/utility.mdx b/cofhe/fhe-library/reference/fhe-sol/utility.mdx similarity index 100% rename from fhe-library/reference/fhe-sol/utility.mdx rename to cofhe/fhe-library/reference/fhe-sol/utility.mdx diff --git a/fhe-library/reference/gas-costs.mdx b/cofhe/fhe-library/reference/gas-costs.mdx similarity index 97% rename from fhe-library/reference/gas-costs.mdx rename to cofhe/fhe-library/reference/gas-costs.mdx index c21d1209..906625f7 100644 --- a/fhe-library/reference/gas-costs.mdx +++ b/cofhe/fhe-library/reference/gas-costs.mdx @@ -58,7 +58,7 @@ Every value is measured on the deployed contracts and rounded to the nearest 100 | Operation | Gas | Types | |---|---|---| -| [Trivial encrypt](/fhe-library/core-concepts/trivial-encryption) `asX(plaintext)` | 45,400 | All | +| [Trivial encrypt](/cofhe/fhe-library/core-concepts/trivial-encryption) `asX(plaintext)` | 45,400 | All | | Encrypted input `asX(InEuintX)` | 39,800 | All | | Encrypted input from bytes `asX(bytes)` | 40,400 | All | | Random `randomX()` | 40,900 | `euint8` to `euint128` | diff --git a/get-started/build-with-ai/ai-assistant.mdx b/cofhe/get-started/build-with-ai/ai-assistant.mdx similarity index 98% rename from get-started/build-with-ai/ai-assistant.mdx rename to cofhe/get-started/build-with-ai/ai-assistant.mdx index f5e396bb..492ec85d 100644 --- a/get-started/build-with-ai/ai-assistant.mdx +++ b/cofhe/get-started/build-with-ai/ai-assistant.mdx @@ -49,7 +49,7 @@ The `fhe-reviewer` subagent backs `fhenix-review` for large diffs and pre-launch The skills are Markdown files under `plugins/fhenix-toolkit/skills/` in the repository. If you work in Cursor, ChatGPT, or another assistant, load the `SKILL.md` for the area you are working in as context, along with its `references/` folder. Every page on this site also carries a menu to open it in ChatGPT, Claude, or Cursor. That is the fastest way to give an assistant the current documentation for one topic. -For prompting techniques that work with any assistant, see [build with AI](/get-started/build-with-ai/build-with-ai). +For prompting techniques that work with any assistant, see [build with AI](/cofhe/get-started/build-with-ai/build-with-ai). ## Status and feedback diff --git a/get-started/build-with-ai/build-with-ai.mdx b/cofhe/get-started/build-with-ai/build-with-ai.mdx similarity index 100% rename from get-started/build-with-ai/build-with-ai.mdx rename to cofhe/get-started/build-with-ai/build-with-ai.mdx diff --git a/get-started/introduction/compatibility.mdx b/cofhe/get-started/introduction/compatibility.mdx similarity index 91% rename from get-started/introduction/compatibility.mdx rename to cofhe/get-started/introduction/compatibility.mdx index 2b54bbc0..5a5df2c6 100644 --- a/get-started/introduction/compatibility.mdx +++ b/cofhe/get-started/introduction/compatibility.mdx @@ -112,7 +112,7 @@ The [official migration guide](https://cofhesdk.fhenix.io/migrating-to-0-7-0) co ## Next steps -- Follow the [quick start guide](/fhe-library/introduction/quick-start) to set up a development environment. -- Read the [best practices](/fhe-library/introduction/best-practices) for building with CoFHE. -- Browse the [`FHE.sol` reference](/fhe-library/reference/fhe-sol/overview) for the contract API. -- Browse the [SDK reference](/client-sdk/reference/sdk-reference), plus the [Hardhat](/client-sdk/reference/hardhat-reference) and [Foundry](/client-sdk/reference/foundry-reference) plugin references, for the client side. +- Follow the [quick start guide](/cofhe/fhe-library/introduction/quick-start) to set up a development environment. +- Read the [best practices](/cofhe/fhe-library/introduction/best-practices) for building with CoFHE. +- Browse the [`FHE.sol` reference](/cofhe/fhe-library/reference/fhe-sol/overview) for the contract API. +- Browse the [SDK reference](/cofhe/client-sdk/reference/sdk-reference), plus the [Hardhat](/cofhe/client-sdk/reference/hardhat-reference) and [Foundry](/cofhe/client-sdk/reference/foundry-reference) plugin references, for the client side. diff --git a/get-started/introduction/fhenix.mdx b/cofhe/get-started/introduction/fhenix.mdx similarity index 100% rename from get-started/introduction/fhenix.mdx rename to cofhe/get-started/introduction/fhenix.mdx diff --git a/get-started/introduction/support-and-feedback.mdx b/cofhe/get-started/introduction/support-and-feedback.mdx similarity index 92% rename from get-started/introduction/support-and-feedback.mdx rename to cofhe/get-started/introduction/support-and-feedback.mdx index ed1cb288..c8a6027e 100644 --- a/get-started/introduction/support-and-feedback.mdx +++ b/cofhe/get-started/introduction/support-and-feedback.mdx @@ -106,7 +106,7 @@ Thank you for being part of our community! Your feedback helps us build better t ## Next Steps - Join our [Discord community](https://discord.gg/FuVgxrvJMY) to connect with other developers -- Check the [Compatibility](/get-started/introduction/compatibility) page if you're experiencing version-related issues -- Review [Common Errors](/fhe-library/core-concepts/common-errors) for troubleshooting guidance -- Explore our [documentation](/fhe-library/introduction/overview) to learn more about CoFHE +- Check the [Compatibility](/cofhe/get-started/introduction/compatibility) page if you're experiencing version-related issues +- Review [Common Errors](/cofhe/fhe-library/core-concepts/common-errors) for troubleshooting guidance +- Explore our [documentation](/cofhe/fhe-library/introduction/overview) to learn more about CoFHE diff --git a/get-started/introduction/what-is-cofhe-explorable.mdx b/cofhe/get-started/introduction/what-is-cofhe-explorable.mdx similarity index 100% rename from get-started/introduction/what-is-cofhe-explorable.mdx rename to cofhe/get-started/introduction/what-is-cofhe-explorable.mdx diff --git a/get-started/introduction/what-is-cofhe.mdx b/cofhe/get-started/introduction/what-is-cofhe.mdx similarity index 65% rename from get-started/introduction/what-is-cofhe.mdx rename to cofhe/get-started/introduction/what-is-cofhe.mdx index 05cd179a..799d64db 100644 --- a/get-started/introduction/what-is-cofhe.mdx +++ b/cofhe/get-started/introduction/what-is-cofhe.mdx @@ -3,7 +3,7 @@ title: What is CoFHE? description: "A high-level introduction to CoFHE, Fhenix's Fully Homomorphic Encryption coprocessor" --- -[FHE](/get-started/introduction/fhenix) explains *why* confidential smart contracts matter. **CoFHE is how Fhenix makes them practical.** +[FHE](/cofhe/get-started/introduction/fhenix) explains *why* confidential smart contracts matter. **CoFHE is how Fhenix makes them practical.** **CoFHE is an FHE coprocessor that lets any blockchain run computations on encrypted data.** @@ -15,8 +15,8 @@ The coprocessor model adds confidentiality without changing how applications are - **No migration**: CoFHE attaches to existing blockchains. Confidential contracts deploy to the networks already in use, not a dedicated FHE L1. - **Familiar code**: contracts pass around lightweight *handles* (references to ciphertexts) rather than the ciphertexts themselves, so they read like normal Solidity. FHE operations add some gas overhead, but the onchain footprint stays small and predictable. -- **No cryptography to implement**: the heavy FHE math runs offchain in the [compute pipeline](/deep-dive/cofhe-components/compute-pipeline). A contract calls `FHE.add`; CoFHE does the rest. -- **Trust-minimized by default**: no machine holds the decryption key whole. Its shares sit with independent partners, and each partner releases its share only to a [Teecryptor](/deep-dive/cofhe-components/teecryptor) enclave that the TEE (Trusted Execution Environment) hardware has attested. Teecryptor reassembles the key in memory and never stores it. +- **No cryptography to implement**: the heavy FHE math runs offchain in the [compute pipeline](/cofhe/deep-dive/cofhe-components/compute-pipeline). A contract calls `FHE.add`; CoFHE does the rest. +- **Trust-minimized by default**: no machine holds the decryption key whole. Its shares sit with independent partners, and each partner releases its share only to a [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor) enclave that the TEE (Trusted Execution Environment) hardware has attested. Teecryptor reassembles the key in memory and never stores it. ## What CoFHE lets you build @@ -34,26 +34,26 @@ Every CoFHE application follows the same three-phase lifecycle: **encrypt to com -The [`@cofhe/sdk`](/client-sdk/introduction/overview) encrypts the user's plaintext in the client. It attaches a zero-knowledge proof that the input is well-formed, then submits both to CoFHE. The blockchain only ever receives an encrypted handle, never the raw value. +The [`@cofhe/sdk`](/cofhe/client-sdk/introduction/overview) encrypts the user's plaintext in the client. It attaches a zero-knowledge proof that the input is well-formed, then submits both to CoFHE. The blockchain only ever receives an encrypted handle, never the raw value. -The smart contract uses [`FHE.sol`](/fhe-library/introduction/overview) to operate on encrypted handles, adding, comparing, selecting, as if they were ordinary numbers. Each operation deterministically derives a new result handle and is recorded onchain. The compute pipeline picks up that record, and the FHE Engine computes the matching ciphertext offchain. Nothing returns to the contract, and plaintext is never exposed at any point. +The smart contract uses [`FHE.sol`](/cofhe/fhe-library/introduction/overview) to operate on encrypted handles, adding, comparing, selecting, as if they were ordinary numbers. Each operation deterministically derives a new result handle and is recorded onchain. The compute pipeline picks up that record, and the FHE Engine computes the matching ciphertext offchain. Nothing returns to the contract, and plaintext is never exposed at any point. -When an authorized user wants a result, they present a signed [Access Control Permission](/client-sdk/guides/acps). Teecryptor checks that permission against the onchain access list, then decrypts inside its enclave. It either seals the value so only that user can read it (for display), or returns a signed plaintext a contract can verify (for onchain use). +When an authorized user wants a result, they present a signed [Access Control Permission](/cofhe/client-sdk/guides/acps). Teecryptor checks that permission against the onchain access list, then decrypts inside its enclave. It either seals the value so only that user can read it (for display), or returns a signed plaintext a contract can verify (for onchain use). {/* Diagram source: what-is-cofhe.mmd, beside this page. Edit it first, then re-run the archify build. */} -Sequence diagram of the how cofhe works +Sequence diagram of the how cofhe works -Color marks the zone. Your app and the Client SDK run client side, your contract on the host chain, and CoFHE offchain. Hover any component or message in the [explorable version](/get-started/introduction/what-is-cofhe-explorable). +Color marks the zone. Your app and the Client SDK run client side, your contract on the host chain, and CoFHE offchain. Hover any component or message in the [explorable version](/cofhe/get-started/introduction/what-is-cofhe-explorable). ## The pieces @@ -64,8 +64,8 @@ Developers only interact directly with **two** parts of CoFHE; the rest runs beh | Component | Where | Role | | --- | --- | --- | -| **[`@cofhe/sdk`](/client-sdk/introduction/overview)** | Client | Encrypt inputs, manage ACPs, decrypt outputs | -| **[`FHE.sol`](/fhe-library/introduction/overview)** | Onchain | Solidity API for operating on encrypted handles | +| **[`@cofhe/sdk`](/cofhe/client-sdk/introduction/overview)** | Client | Encrypt inputs, manage ACPs, decrypt outputs | +| **[`FHE.sol`](/cofhe/fhe-library/introduction/overview)** | Onchain | Solidity API for operating on encrypted handles | ### What runs behind the scenes @@ -77,7 +77,7 @@ Developers only interact directly with **two** parts of CoFHE; the rest runs beh | **Teecryptor** | Decrypts inside a hardware-attested TEE, after checking permissions and commitments | | **CommitmentRegistry** | Records a commitment for every ciphertext, so integrity is verified before any decryption | -For a component-by-component breakdown, see the [CoFHE Architecture deep dive](/deep-dive/cofhe-components/overview). +For a component-by-component breakdown, see the [CoFHE Architecture deep dive](/cofhe/deep-dive/cofhe-components/overview). ## How CoFHE keeps data safe @@ -90,19 +90,19 @@ For a component-by-component breakdown, see the [CoFHE Architecture deep dive](/ - + Walk through encrypt to compute to decrypt with a concrete Counter example. - + The TypeScript SDK for encrypting inputs and decrypting outputs. - + The Solidity library for computing on encrypted data onchain. - + Every CoFHE component and data flow, in detail. diff --git a/get-started/introduction/what-is-cofhe.mmd b/cofhe/get-started/introduction/what-is-cofhe.mmd similarity index 100% rename from get-started/introduction/what-is-cofhe.mmd rename to cofhe/get-started/introduction/what-is-cofhe.mmd diff --git a/images/commitment-registry.svg b/cofhe/images/commitment-registry.svg similarity index 100% rename from images/commitment-registry.svg rename to cofhe/images/commitment-registry.svg diff --git a/images/commitment-version.svg b/cofhe/images/commitment-version.svg similarity index 100% rename from images/commitment-version.svg rename to cofhe/images/commitment-version.svg diff --git a/images/compute-pipeline.svg b/cofhe/images/compute-pipeline.svg similarity index 100% rename from images/compute-pipeline.svg rename to cofhe/images/compute-pipeline.svg diff --git a/images/decryption-request-flow.svg b/cofhe/images/decryption-request-flow.svg similarity index 100% rename from images/decryption-request-flow.svg rename to cofhe/images/decryption-request-flow.svg diff --git a/images/encryption-request-flow.svg b/cofhe/images/encryption-request-flow.svg similarity index 100% rename from images/encryption-request-flow.svg rename to cofhe/images/encryption-request-flow.svg diff --git a/images/fhe-operation-request-flow.svg b/cofhe/images/fhe-operation-request-flow.svg similarity index 100% rename from images/fhe-operation-request-flow.svg rename to cofhe/images/fhe-operation-request-flow.svg diff --git a/images/key-management.svg b/cofhe/images/key-management.svg similarity index 100% rename from images/key-management.svg rename to cofhe/images/key-management.svg diff --git a/images/mental-model.svg b/cofhe/images/mental-model.svg similarity index 100% rename from images/mental-model.svg rename to cofhe/images/mental-model.svg diff --git a/images/overview.svg b/cofhe/images/overview.svg similarity index 100% rename from images/overview.svg rename to cofhe/images/overview.svg diff --git a/images/teecryptor.svg b/cofhe/images/teecryptor.svg similarity index 100% rename from images/teecryptor.svg rename to cofhe/images/teecryptor.svg diff --git a/images/verify-commitments.svg b/cofhe/images/verify-commitments.svg similarity index 100% rename from images/verify-commitments.svg rename to cofhe/images/verify-commitments.svg diff --git a/images/what-is-cofhe.svg b/cofhe/images/what-is-cofhe.svg similarity index 100% rename from images/what-is-cofhe.svg rename to cofhe/images/what-is-cofhe.svg diff --git a/images/zk-verifier.svg b/cofhe/images/zk-verifier.svg similarity index 100% rename from images/zk-verifier.svg rename to cofhe/images/zk-verifier.svg diff --git a/index.mdx b/cofhe/index.mdx similarity index 61% rename from index.mdx rename to cofhe/index.mdx index 90e90427..5bf4095c 100644 --- a/index.mdx +++ b/cofhe/index.mdx @@ -12,11 +12,11 @@ Fhenix enables developers to build privacy-preserving smart contracts using Full Get up and running with Fhenix in minutes. - + Set up your development environment and build your first FHE-enabled smart contract. - + Learn the fundamentals by building an encrypted counter contract. @@ -24,19 +24,19 @@ Learn the fundamentals by building an encrypted counter contract. ## Key resources - + JavaScript library for encrypting inputs, managing ACPs, and decrypting outputs. - + Solidity library for performing operations on encrypted data in smart contracts. - + Complete API documentation for all FHE library functions and operations. - + Step-by-step guides for building FHE-enabled applications. @@ -44,15 +44,15 @@ Step-by-step guides for building FHE-enabled applications. ## Learn more - + Check version compatibility and supported networks. - + Security considerations and optimization techniques. - + Get help and provide feedback to the team. diff --git a/tutorials/acl-usage-examples.mdx b/cofhe/tutorials/acl-usage-examples.mdx similarity index 94% rename from tutorials/acl-usage-examples.mdx rename to cofhe/tutorials/acl-usage-examples.mdx index 5805381d..7fab7385 100644 --- a/tutorials/acl-usage-examples.mdx +++ b/cofhe/tutorials/acl-usage-examples.mdx @@ -7,7 +7,7 @@ description: "Practical examples of using Access Control Lists (ACL) to manage p This tutorial provides practical examples of using Access Control Lists (ACL) to manage permissions for encrypted data in your CoFHE contracts. -See [ACL Mechanism](/fhe-library/core-concepts/access-control) for explanation of why the ACL mechanism is needed. +See [ACL Mechanism](/cofhe/fhe-library/core-concepts/access-control) for explanation of why the ACL mechanism is needed. ## Solidity API @@ -193,6 +193,6 @@ When passing encrypted values to other contracts for a single operation, use `FH ## Next Steps -- Learn more about [Access Control](/fhe-library/core-concepts/access-control) mechanisms -- Review [Your First FHE Contract](/tutorials/your-first-fhe-contract) for a complete example -- Explore [Adding FHE to an Existing Contract](/tutorials/adding-fhe-to-existing-contract) for migration patterns +- Learn more about [Access Control](/cofhe/fhe-library/core-concepts/access-control) mechanisms +- Review [Your First FHE Contract](/cofhe/tutorials/your-first-fhe-contract) for a complete example +- Explore [Adding FHE to an Existing Contract](/cofhe/tutorials/adding-fhe-to-existing-contract) for migration patterns diff --git a/tutorials/adding-fhe-to-existing-contract.mdx b/cofhe/tutorials/adding-fhe-to-existing-contract.mdx similarity index 97% rename from tutorials/adding-fhe-to-existing-contract.mdx rename to cofhe/tutorials/adding-fhe-to-existing-contract.mdx index bb99ebf6..7a0c7297 100644 --- a/tutorials/adding-fhe-to-existing-contract.mdx +++ b/cofhe/tutorials/adding-fhe-to-existing-contract.mdx @@ -240,9 +240,9 @@ contract VotingExample { We now need to handle the user's vote casting. The first thing that we need to do is hide which option the user is voting for. We can do this by replacing the `vote` function parameter `uint256 _optionIndex` with two parameters: `externalEuint8 _optionIndex`, the encrypted input handle, and `bytes calldata inputProof`, the proof that authenticates it. `FHE.asEuint8(_optionIndex, inputProof)` then converts the pair into an `euint8` for use in computation. -Encrypting inputs requires the use of the [**Client SDK**](/client-sdk/introduction/overview) (`@cofhe/sdk`). +Encrypting inputs requires the use of the [**Client SDK**](/cofhe/client-sdk/introduction/overview) (`@cofhe/sdk`). -Read more about [**encrypted inputs**](/client-sdk/guides/encrypting-inputs). +Read more about [**encrypted inputs**](/cofhe/client-sdk/guides/encrypting-inputs). ```solidity @@ -439,7 +439,7 @@ function revealResults( } ``` -The client-side flow looks like this. It assumes a connected `client` (see [client setup](/client-sdk/guides/client-setup)), viem `publicClient` and `walletClient` instances, the contract ABI as `votingAbi`, and its address as `votingAddress`: +The client-side flow looks like this. It assumes a connected `client` (see [client setup](/cofhe/client-sdk/guides/client-setup)), viem `publicClient` and `walletClient` instances, the contract ABI as `votingAbi`, and its address as `votingAddress`: ```typescript // 1. Finalize the vote (owner only) @@ -774,6 +774,6 @@ contract FHEVotingExample { ## Next Steps -- Learn about [Migrating from FHE.decrypt](/tutorials/migrating-from-fhe-decrypt) to the new decryption flow -- Explore [ACL Usage Examples](/tutorials/acl-usage-examples) for complex access control patterns -- Review [Best Practices](/fhe-library/introduction/best-practices) for security considerations +- Learn about [Migrating from FHE.decrypt](/cofhe/tutorials/migrating-from-fhe-decrypt) to the new decryption flow +- Explore [ACL Usage Examples](/cofhe/tutorials/acl-usage-examples) for complex access control patterns +- Review [Best Practices](/cofhe/fhe-library/introduction/best-practices) for security considerations diff --git a/tutorials/migrating-from-fhe-decrypt.mdx b/cofhe/tutorials/migrating-from-fhe-decrypt.mdx similarity index 92% rename from tutorials/migrating-from-fhe-decrypt.mdx rename to cofhe/tutorials/migrating-from-fhe-decrypt.mdx index c8850a7c..a1cff001 100644 --- a/tutorials/migrating-from-fhe-decrypt.mdx +++ b/cofhe/tutorials/migrating-from-fhe-decrypt.mdx @@ -21,7 +21,7 @@ This guide walks through concrete before/after Solidity examples. | **Read result** | `FHE.getDecryptResultSafe(ctHash)` | `FHE.getDecryptResultSafe(ctHash)` (same) | -The key difference: `FHE.decrypt` triggered decryption without any proof. The new flow returns a signature from [Teecryptor](/deep-dive/cofhe-components/teecryptor), which decrypts inside a hardware-attested TEE. Your contract verifies that signature before it uses the plaintext. +The key difference: `FHE.decrypt` triggered decryption without any proof. The new flow returns a signature from [Teecryptor](/cofhe/deep-dive/cofhe-components/teecryptor), which decrypts inside a hardware-attested TEE. Your contract verifies that signature before it uses the plaintext. --- @@ -68,7 +68,7 @@ FHE.verifyDecryptResult(encryptedValue, plaintext, signature); -Teecryptor decrypts today. A multi-party Threshold Network is the planned replacement; see [Future Plans](/deep-dive/research/future-plans). +Teecryptor decrypts today. A multi-party Threshold Network is the planned replacement; see [Future Plans](/cofhe/deep-dive/research/future-plans). --- @@ -156,7 +156,7 @@ const value = await counter.get_counter_value(); The unshield flow is where `FHE.decrypt` was most commonly used. It already followed a two-step pattern (unshield + claim), which maps naturally to the new flow. -This example is a minimal wrapper written to show the migration. The FHERC20 wrappers in `fhenix-confidential-contracts` key claims by a claim ID rather than by the handle, because two unshields can produce the same handle. To use those contracts, follow [wrap ERC-20 tokens and ETH](/fhe-library/confidential-contracts/fherc20/fherc20-wrapper). +This example is a minimal wrapper written to show the migration. The FHERC20 wrappers in `fhenix-confidential-contracts` key claims by a claim ID rather than by the handle, because two unshields can produce the same handle. To use those contracts, follow [wrap ERC-20 tokens and ETH](/cofhe/fhe-library/confidential-contracts/fherc20/fherc20-wrapper). @@ -355,7 +355,7 @@ Add the offchain decryption step using `client.decryptForTx()` between the two o ## Next steps -- Read about [Decryption Operations](/fhe-library/core-concepts/decryption-operations) for the full reference -- See [Adding FHE to an Existing Contract](/tutorials/adding-fhe-to-existing-contract) for a complete contract migration -- Learn about [Access Control](/fhe-library/core-concepts/access-control) for managing decrypt permissions -- Check the [Client SDK decrypt guide](/client-sdk/guides/decrypt-to-tx) for the full client-side API +- Read about [Decryption Operations](/cofhe/fhe-library/core-concepts/decryption-operations) for the full reference +- See [Adding FHE to an Existing Contract](/cofhe/tutorials/adding-fhe-to-existing-contract) for a complete contract migration +- Learn about [Access Control](/cofhe/fhe-library/core-concepts/access-control) for managing decrypt permissions +- Check the [Client SDK decrypt guide](/cofhe/client-sdk/guides/decrypt-to-tx) for the full client-side API diff --git a/tutorials/overview.mdx b/cofhe/tutorials/overview.mdx similarity index 52% rename from tutorials/overview.mdx rename to cofhe/tutorials/overview.mdx index a854e040..ea7a724f 100644 --- a/tutorials/overview.mdx +++ b/cofhe/tutorials/overview.mdx @@ -13,8 +13,8 @@ Start your CoFHE journey with these foundational tutorials designed to get you u | Tutorial | Description | |----------|-------------| -| [Quick Start](/fhe-library/introduction/quick-start) | Set up your environment for FHE enabled development and testing | -| [Best Practices](/fhe-library/introduction/best-practices) | Discover security and performance optimization techniques for FHE development | +| [Quick Start](/cofhe/fhe-library/introduction/quick-start) | Set up your environment for FHE enabled development and testing | +| [Best Practices](/cofhe/fhe-library/introduction/best-practices) | Discover security and performance optimization techniques for FHE development | ## Advanced Tutorials @@ -22,10 +22,10 @@ Once you've mastered the basics, dive deeper with these specialized tutorials: | Tutorial | Description | |----------|-------------| -| [Your First FHE Contract](/tutorials/your-first-fhe-contract) | Build a simple encrypted counter contract to understand fundamental FHE concepts | -| [Adding FHE to an Existing Contract](/tutorials/adding-fhe-to-existing-contract) | Learn how to transform traditional smart contracts into privacy-preserving ones | -| [Migrating from FHE.decrypt](/tutorials/migrating-from-fhe-decrypt) | Migrate from the old `FHE.decrypt` pattern to the new `allowPublic` + `publishDecryptResult` flow | -| [ACL Usage Examples](/tutorials/acl-usage-examples) | Implement common access control mechanisms for encrypted data | +| [Your First FHE Contract](/cofhe/tutorials/your-first-fhe-contract) | Build a simple encrypted counter contract to understand fundamental FHE concepts | +| [Adding FHE to an Existing Contract](/cofhe/tutorials/adding-fhe-to-existing-contract) | Learn how to transform traditional smart contracts into privacy-preserving ones | +| [Migrating from FHE.decrypt](/cofhe/tutorials/migrating-from-fhe-decrypt) | Migrate from the old `FHE.decrypt` pattern to the new `allowPublic` + `publishDecryptResult` flow | +| [ACL Usage Examples](/cofhe/tutorials/acl-usage-examples) | Implement common access control mechanisms for encrypted data | Ready to start your privacy-preserving blockchain development journey? Choose a tutorial from the table above and dive in! diff --git a/tutorials/your-first-fhe-contract.mdx b/cofhe/tutorials/your-first-fhe-contract.mdx similarity index 91% rename from tutorials/your-first-fhe-contract.mdx rename to cofhe/tutorials/your-first-fhe-contract.mdx index c13ebf9c..2c787ef3 100644 --- a/tutorials/your-first-fhe-contract.mdx +++ b/cofhe/tutorials/your-first-fhe-contract.mdx @@ -79,7 +79,7 @@ contract SimpleCounter { To start using FHE, we need to import the FHE library. -In this example, we're importing the types `euint64` and `externalEuint64` from the [FHE library](/fhe-library/reference/fhe-sol/overview). +In this example, we're importing the types `euint64` and `externalEuint64` from the [FHE library](/cofhe/fhe-library/reference/fhe-sol/overview). ```solidity import {FHE, euint64, externalEuint64} from "@fhenixprotocol/cofhe-contracts/FHE.sol"; @@ -120,7 +120,7 @@ When we initialize the `delta` and `counter` variables, we use **trivial encrypt To make it completely private, initialize these variables from an encrypted input sent by the client (an `externalEuint64` handle plus its proof), the same way `reset_counter` does. -Read more on the [trivial encryption](/fhe-library/core-concepts/trivial-encryption) page. +Read more on the [trivial encryption](/cofhe/fhe-library/core-concepts/trivial-encryption) page. ### Access control @@ -131,7 +131,7 @@ For every encrypted variable, we need to call `FHE.allowThis()` to allow the con Without it, the contract could not continue to use this encrypted variable in future transactions. -You can read more about this in the [ACL Mechanism](/fhe-library/core-concepts/access-control) page. +You can read more about this in the [ACL Mechanism](/cofhe/fhe-library/core-concepts/access-control) page. ```solidity FHE.allowThis(counter); @@ -153,7 +153,7 @@ FHE.allowThis(counter); In the `reset_counter` function, we receive an `externalEuint64` handle and the `bytes` proof that authenticates it. Together they represent an encrypted value that can be used to reset the counter, and `FHE.asEuint64(value, inputProof)` converts the pair into a `euint64` the contract can compute on. -Both come from the client, created with the SDK. See [encrypting inputs](/client-sdk/guides/encrypting-inputs). +Both come from the client, created with the SDK. See [encrypting inputs](/cofhe/client-sdk/guides/encrypting-inputs). ### Decryption: allow public and reveal @@ -171,7 +171,7 @@ function allow_counter_publicly() external onlyOwner { **Step 2: Decrypt offchain** -Anyone can now request decryption offchain with `decryptForTx`. The Teecryptor (the TEE decryption service) returns the plaintext value and a signature over it. The client snippets on this page assume a connected `client` (see [client setup](/client-sdk/guides/client-setup)), viem `publicClient` and `walletClient` instances, and the contract ABI as `simpleCounterAbi`. +Anyone can now request decryption offchain with `decryptForTx`. The Teecryptor (the TEE decryption service) returns the plaintext value and a signature over it. The client snippets on this page assume a connected `client` (see [client setup](/cofhe/client-sdk/guides/client-setup)), viem `publicClient` and `walletClient` instances, and the contract ABI as `simpleCounterAbi`. The contract keeps `counter` private, so read the handle through `get_encrypted_counter_value`: @@ -270,6 +270,6 @@ console.log(`Counter value (private): ${plaintext}`); ## Next steps -- Explore [Adding FHE to an Existing Contract](/tutorials/adding-fhe-to-existing-contract) -- Review [ACL Usage Examples](/tutorials/acl-usage-examples) for more access control patterns -- Understand [Decryption Operations](/fhe-library/core-concepts/decryption-operations) in detail +- Explore [Adding FHE to an Existing Contract](/cofhe/tutorials/adding-fhe-to-existing-contract) +- Review [ACL Usage Examples](/cofhe/tutorials/acl-usage-examples) for more access control patterns +- Understand [Decryption Operations](/cofhe/fhe-library/core-concepts/decryption-operations) in detail diff --git a/deep-dive/cofhe-components/overview.mdx b/deep-dive/cofhe-components/overview.mdx deleted file mode 100644 index 2b3f4f3d..00000000 --- a/deep-dive/cofhe-components/overview.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "CoFHE Architecture Overview" -description: "How CoFHE's onchain contracts and offchain components fit together to run FHE computations for any EVM chain" ---- - -CoFHE (Coprocessor for Fully Homomorphic Encryption) lets smart contracts compute on encrypted data. Contracts request operations through onchain calls; a set of offchain components executes them and commits to the results. Data stays encrypted until an authorized decryption, and every result can be verified against an onchain commitment. - -{/* Diagram source: overview.mmd, beside this page. Edit it first, then re-run the archify build. */} - -CoFHE architecture: the Client SDK above your contracts on the host chain, the independent partners above CoFHE offchain with the ZK Verifier, Teecryptor, the ciphertext store and the compute pipeline, and the CommitmentRegistry on the registry chain to the right - - - -Color marks the zone, and the boxes group what runs where. Each component is described under [the onchain contracts](#the-onchain-contracts) and [the offchain components](#the-offchain-components) below. - - -## The onchain contracts - -- **FHE.sol**: the Solidity library your contract imports. It exposes arithmetic, comparison, and logical operations on encrypted values, plus access control (`allow`, `allowGlobal`) and decrypt-result verification. -- **CoFHEAddressBook**: deployed at `0xC0F4e00E531a2B086492Ae3DCC1515038307196b` on every supported chain, mainnet and testnet. It maps a TaskManager id to that chain's TaskManager, and `FHE.sol` finds the TaskManager through it with id `1`. -- **[TaskManager](/deep-dive/cofhe-components/task-manager)**: the gateway for all FHE operation requests. It validates requests, emits task events for the offchain components, and manages permissions through the ACL. -- **[ACL](/deep-dive/cofhe-components/acl)**: the access control contract. It records who may use or decrypt each handle; all writes to it go through the TaskManager. -- **[PlaintextsStorage](/deep-dive/cofhe-components/plaintext-storage)**: stores decrypted results. The TaskManager writes them during `publishDecryptResult`, only after ECDSA-verifying the result against `decryptResultSigner`. -- **[CommitmentRegistry](/deep-dive/cofhe-components/commitment-registry)**: lives on a dedicated registry chain and records a hash commitment for every ciphertext the coprocessor produces or verifies. Teecryptor verifies integrity against it before decrypting anything. - -## The offchain components - -- **[Client SDK](/client-sdk/introduction/overview)** (`@cofhe/sdk`): the TypeScript library applications use to encrypt inputs, manage [Access Control Permissions](/client-sdk/guides/acps) (ACPs), and decrypt outputs. -- **[ZK Verifier](/deep-dive/cofhe-components/zk-verifier)**: verifies encrypted inputs in batches, inside a hardware-attested TEE. It checks each zero-knowledge proof, stores the ciphertexts, and signs one approval for the whole batch. -- **[Compute pipeline](/deep-dive/cofhe-components/compute-pipeline)**: the execution pipeline. It subscribes to TaskManager events, validates and orders operations, runs them on encrypted data, and posts a commitment for every result. -- **Ciphertext store**: the database that holds every ciphertext, fronted by the CT Server. The ZK Verifier writes verified inputs, the FHE Engine reads operands and writes results, and Teecryptor fetches bytes to decrypt. -- **[Teecryptor](/deep-dive/cofhe-components/teecryptor)**: the decryption component. It runs inside a hardware-attested TEE, authorizes every request against the onchain ACL, verifies the ciphertext commitment, and returns signed or sealed results. -- **Partners**: independent custodians of the key material. Each holds a Shamir share and releases it only to an attested enclave. See [Key Management](/deep-dive/cofhe-components/key-management). - -## Data flows - -1. **[Encryption request](/deep-dive/data-flows/encryption-request-flow)**: an input is encrypted client-side and proven valid with a zero-knowledge proof before it enters the chain. -2. **[FHE operation](/deep-dive/data-flows/fhe-operation-request-flow)**: a contract requests a computation; the coprocessor executes it and commits to the result. -3. **[Decryption](/deep-dive/data-flows/decryption-request-flow)**: the SDK asks Teecryptor to decrypt a handle, either as a signed plaintext for onchain publication or sealed to an ACP for offchain reads. - -## Future plans - -Two components run inside hardware-attested TEEs today: Teecryptor, which decrypts, and the ZK Verifier, which checks input proofs. Both move to multi-party computation in one planned step. See [Future Plans](/deep-dive/research/future-plans). diff --git a/docs.json b/docs.json index 4d9e271a..329debc3 100644 --- a/docs.json +++ b/docs.json @@ -18,267 +18,273 @@ }, "favicon": "/favicon.svg", "navigation": { - "tabs": [ + "products": [ { - "tab": "Get Started", - "global": { - "anchors": [ - { - "anchor": "Website", - "href": "https://www.fhenix.io/", - "icon": "globe" - }, - { - "anchor": "Blog", - "href": "https://www.fhenix.io/blog", - "icon": "newspaper" - } - ] - }, - "groups": [ - { - "group": "Introduction", - "pages": [ - "index", - "get-started/introduction/fhenix", - "get-started/introduction/what-is-cofhe", - "get-started/introduction/compatibility", - "get-started/introduction/support-and-feedback" - ] - }, - { - "group": "Build with AI", - "pages": [ - "get-started/build-with-ai/build-with-ai", - "get-started/build-with-ai/ai-assistant" - ] - } - ] - }, - { - "tab": "Client SDK", - "global": { - "anchors": [ - { - "anchor": "Github", - "href": "https://github.com/FhenixProtocol/cofhesdk", - "icon": "github" - } - ] - }, - "groups": [ + "product": "CoFHE", + "icon": "lock", + "tabs": [ { - "group": "Introduction", - "pages": [ - "client-sdk/introduction/overview", - "client-sdk/introduction/mental-model", - "client-sdk/introduction/installation", - "client-sdk/introduction/migrating-to-0-7", - "client-sdk/introduction/migrating-from-cofhejs" - ] - }, - { - "group": "Quick Start", - "pages": [ - "client-sdk/quick-start/javascript", - "client-sdk/quick-start/hardhat", - "client-sdk/quick-start/foundry", - "client-sdk/quick-start/react" - ] - }, - { - "group": "Guides", - "pages": [ - "client-sdk/guides/client-setup", - "client-sdk/guides/encrypting-inputs", - "client-sdk/guides/writing-encrypted-data", - "client-sdk/guides/acps", - "client-sdk/guides/decrypt-to-view", - "client-sdk/guides/decrypt-to-tx", - "client-sdk/guides/writing-decrypt-result", - "client-sdk/guides/error-handling" - ] - }, - { - "group": "Hardhat Plugin", - "pages": [ - "client-sdk/hardhat-plugin/getting-started", - "client-sdk/hardhat-plugin/client", - "client-sdk/hardhat-plugin/mock-contracts", - "client-sdk/hardhat-plugin/logging", - "client-sdk/hardhat-plugin/testing" - ] - }, - { - "group": "Hardhat 3 Plugin", - "pages": [ - "client-sdk/hardhat-3-plugin/getting-started", - "client-sdk/hardhat-3-plugin/client", - "client-sdk/hardhat-3-plugin/mock-contracts", - "client-sdk/hardhat-3-plugin/logging", - "client-sdk/hardhat-3-plugin/testing" - ] - }, - { - "group": "Foundry Plugin", - "pages": [ - "client-sdk/foundry-plugin/getting-started", - "client-sdk/foundry-plugin/cofhe-test", - "client-sdk/foundry-plugin/cofhe-client", - "client-sdk/foundry-plugin/testing" - ] - }, - { - "group": "Examples", - "pages": [ - "client-sdk/examples/end-to-end", - "client-sdk/examples/templates" - ] - }, - { - "group": "Reference", - "pages": [ - "client-sdk/reference/sdk-reference", - "client-sdk/reference/hardhat-reference", - "client-sdk/reference/foundry-reference" - ] - } - ] - }, - { - "tab": "FHE library", - "groups": [ - { - "group": "Introduction", - "pages": [ - "fhe-library/introduction/overview", - "fhe-library/introduction/quick-start", - "fhe-library/introduction/best-practices" - ] - }, - { - "group": "Core Concepts", - "pages": [ - "fhe-library/core-concepts/inputs", - "fhe-library/core-concepts/handles", - "fhe-library/core-concepts/trivial-encryption", - "fhe-library/core-concepts/data-evaluation", - "fhe-library/core-concepts/encrypted-operations", - "fhe-library/core-concepts/conditions", - "fhe-library/core-concepts/require", - "fhe-library/core-concepts/access-control", - "fhe-library/core-concepts/decryption-operations", - "fhe-library/core-concepts/randomness", - "fhe-library/core-concepts/gas-and-benchmarks", - "fhe-library/core-concepts/common-errors" - ] - }, - { - "group": "Confidential Contracts", - "pages": [ - "fhe-library/confidential-contracts/overview", - "fhe-library/confidential-contracts/calling-from-contracts", - "fhe-library/confidential-contracts/upgradeable", + "tab": "Get Started", + "global": { + "anchors": [ + { + "anchor": "Website", + "href": "https://www.fhenix.io/", + "icon": "globe" + }, + { + "anchor": "Blog", + "href": "https://www.fhenix.io/blog", + "icon": "newspaper" + } + ] + }, + "groups": [ { - "group": "FHERC20", + "group": "Introduction", "pages": [ - "fhe-library/confidential-contracts/fherc20/overview", - "fhe-library/confidential-contracts/fherc20/core-features", - "fhe-library/confidential-contracts/fherc20/operators", - "fhe-library/confidential-contracts/fherc20/transfer-callbacks", - "fhe-library/confidential-contracts/fherc20/fherc20-wrapper", - "fhe-library/confidential-contracts/fherc20/best-practices" + "cofhe/index", + "cofhe/get-started/introduction/fhenix", + "cofhe/get-started/introduction/what-is-cofhe", + "cofhe/get-started/introduction/compatibility", + "cofhe/get-started/introduction/support-and-feedback" ] }, { - "group": "ERC20Confidential", + "group": "Build with AI", "pages": [ - "fhe-library/confidential-contracts/dual-mode/overview", - "fhe-library/confidential-contracts/dual-mode/dual-balance-model", - "fhe-library/confidential-contracts/dual-mode/shield-unshield", - "fhe-library/confidential-contracts/dual-mode/confidential-operations", - "fhe-library/confidential-contracts/dual-mode/extending", - "fhe-library/confidential-contracts/dual-mode/best-practices" + "cofhe/get-started/build-with-ai/build-with-ai", + "cofhe/get-started/build-with-ai/ai-assistant" ] } ] }, { - "group": "Examples", - "pages": [ - "fhe-library/examples/auction-example" + "tab": "Client SDK", + "global": { + "anchors": [ + { + "anchor": "Github", + "href": "https://github.com/FhenixProtocol/cofhesdk", + "icon": "github" + } + ] + }, + "groups": [ + { + "group": "Introduction", + "pages": [ + "cofhe/client-sdk/introduction/overview", + "cofhe/client-sdk/introduction/mental-model", + "cofhe/client-sdk/introduction/installation", + "cofhe/client-sdk/introduction/migrating-to-0-7", + "cofhe/client-sdk/introduction/migrating-from-cofhejs" + ] + }, + { + "group": "Quick Start", + "pages": [ + "cofhe/client-sdk/quick-start/javascript", + "cofhe/client-sdk/quick-start/hardhat", + "cofhe/client-sdk/quick-start/foundry", + "cofhe/client-sdk/quick-start/react" + ] + }, + { + "group": "Guides", + "pages": [ + "cofhe/client-sdk/guides/client-setup", + "cofhe/client-sdk/guides/encrypting-inputs", + "cofhe/client-sdk/guides/writing-encrypted-data", + "cofhe/client-sdk/guides/acps", + "cofhe/client-sdk/guides/decrypt-to-view", + "cofhe/client-sdk/guides/decrypt-to-tx", + "cofhe/client-sdk/guides/writing-decrypt-result", + "cofhe/client-sdk/guides/error-handling" + ] + }, + { + "group": "Hardhat Plugin", + "pages": [ + "cofhe/client-sdk/hardhat-plugin/getting-started", + "cofhe/client-sdk/hardhat-plugin/client", + "cofhe/client-sdk/hardhat-plugin/mock-contracts", + "cofhe/client-sdk/hardhat-plugin/logging", + "cofhe/client-sdk/hardhat-plugin/testing" + ] + }, + { + "group": "Hardhat 3 Plugin", + "pages": [ + "cofhe/client-sdk/hardhat-3-plugin/getting-started", + "cofhe/client-sdk/hardhat-3-plugin/client", + "cofhe/client-sdk/hardhat-3-plugin/mock-contracts", + "cofhe/client-sdk/hardhat-3-plugin/logging", + "cofhe/client-sdk/hardhat-3-plugin/testing" + ] + }, + { + "group": "Foundry Plugin", + "pages": [ + "cofhe/client-sdk/foundry-plugin/getting-started", + "cofhe/client-sdk/foundry-plugin/cofhe-test", + "cofhe/client-sdk/foundry-plugin/cofhe-client", + "cofhe/client-sdk/foundry-plugin/testing" + ] + }, + { + "group": "Examples", + "pages": [ + "cofhe/client-sdk/examples/end-to-end", + "cofhe/client-sdk/examples/templates" + ] + }, + { + "group": "Reference", + "pages": [ + "cofhe/client-sdk/reference/sdk-reference", + "cofhe/client-sdk/reference/hardhat-reference", + "cofhe/client-sdk/reference/foundry-reference" + ] + } ] }, { - "group": "Reference", - "pages": [ + "tab": "FHE library", + "groups": [ { - "group": "FHE.sol", + "group": "Introduction", "pages": [ - "fhe-library/reference/fhe-sol/overview", - "fhe-library/reference/fhe-sol/type-conversion", - "fhe-library/reference/fhe-sol/arithmetic", - "fhe-library/reference/fhe-sol/bitwise", - "fhe-library/reference/fhe-sol/comparison", - "fhe-library/reference/fhe-sol/decryption", - "fhe-library/reference/fhe-sol/access-control", - "fhe-library/reference/fhe-sol/utility", - "fhe-library/reference/fhe-sol/bindings" + "cofhe/fhe-library/introduction/overview", + "cofhe/fhe-library/introduction/quick-start", + "cofhe/fhe-library/introduction/best-practices" ] }, - "fhe-library/reference/gas-costs", - "fhe-library/reference/cofhe-errors", - "fhe-library/reference/cofhe-errors-reference" - ] - } - ] - }, - { - "tab": "Tutorials", - "groups": [ - { - "group": "Tutorials", - "pages": [ - "tutorials/overview", - "tutorials/migrating-from-fhe-decrypt", - "tutorials/your-first-fhe-contract", - "tutorials/adding-fhe-to-existing-contract", - "tutorials/acl-usage-examples" - ] - } - ] - }, - { - "tab": "Deep Dive", - "groups": [ - { - "group": "CoFHE Components", - "pages": [ - "deep-dive/cofhe-components/overview", - "deep-dive/cofhe-components/task-manager", - "deep-dive/cofhe-components/acl", - "deep-dive/cofhe-components/plaintext-storage", - "deep-dive/cofhe-components/commitment-registry", - "deep-dive/cofhe-components/verify-commitments", - "deep-dive/cofhe-components/zk-verifier", - "deep-dive/cofhe-components/compute-pipeline", - "deep-dive/cofhe-components/teecryptor", - "deep-dive/cofhe-components/key-management" + { + "group": "Core Concepts", + "pages": [ + "cofhe/fhe-library/core-concepts/inputs", + "cofhe/fhe-library/core-concepts/handles", + "cofhe/fhe-library/core-concepts/trivial-encryption", + "cofhe/fhe-library/core-concepts/data-evaluation", + "cofhe/fhe-library/core-concepts/encrypted-operations", + "cofhe/fhe-library/core-concepts/conditions", + "cofhe/fhe-library/core-concepts/require", + "cofhe/fhe-library/core-concepts/access-control", + "cofhe/fhe-library/core-concepts/decryption-operations", + "cofhe/fhe-library/core-concepts/randomness", + "cofhe/fhe-library/core-concepts/gas-and-benchmarks", + "cofhe/fhe-library/core-concepts/common-errors" + ] + }, + { + "group": "Confidential Contracts", + "pages": [ + "cofhe/fhe-library/confidential-contracts/overview", + "cofhe/fhe-library/confidential-contracts/calling-from-contracts", + "cofhe/fhe-library/confidential-contracts/upgradeable", + { + "group": "FHERC20", + "pages": [ + "cofhe/fhe-library/confidential-contracts/fherc20/overview", + "cofhe/fhe-library/confidential-contracts/fherc20/core-features", + "cofhe/fhe-library/confidential-contracts/fherc20/operators", + "cofhe/fhe-library/confidential-contracts/fherc20/transfer-callbacks", + "cofhe/fhe-library/confidential-contracts/fherc20/fherc20-wrapper", + "cofhe/fhe-library/confidential-contracts/fherc20/best-practices" + ] + }, + { + "group": "ERC20Confidential", + "pages": [ + "cofhe/fhe-library/confidential-contracts/dual-mode/overview", + "cofhe/fhe-library/confidential-contracts/dual-mode/dual-balance-model", + "cofhe/fhe-library/confidential-contracts/dual-mode/shield-unshield", + "cofhe/fhe-library/confidential-contracts/dual-mode/confidential-operations", + "cofhe/fhe-library/confidential-contracts/dual-mode/extending", + "cofhe/fhe-library/confidential-contracts/dual-mode/best-practices" + ] + } + ] + }, + { + "group": "Examples", + "pages": [ + "cofhe/fhe-library/examples/auction-example" + ] + }, + { + "group": "Reference", + "pages": [ + { + "group": "FHE.sol", + "pages": [ + "cofhe/fhe-library/reference/fhe-sol/overview", + "cofhe/fhe-library/reference/fhe-sol/type-conversion", + "cofhe/fhe-library/reference/fhe-sol/arithmetic", + "cofhe/fhe-library/reference/fhe-sol/bitwise", + "cofhe/fhe-library/reference/fhe-sol/comparison", + "cofhe/fhe-library/reference/fhe-sol/decryption", + "cofhe/fhe-library/reference/fhe-sol/access-control", + "cofhe/fhe-library/reference/fhe-sol/utility", + "cofhe/fhe-library/reference/fhe-sol/bindings" + ] + }, + "cofhe/fhe-library/reference/gas-costs", + "cofhe/fhe-library/reference/cofhe-errors", + "cofhe/fhe-library/reference/cofhe-errors-reference" + ] + } ] }, { - "group": "Data Flows", - "pages": [ - "deep-dive/data-flows/encryption-request-flow", - "deep-dive/data-flows/fhe-operation-request-flow", - "deep-dive/data-flows/decryption-request-flow" + "tab": "Tutorials", + "groups": [ + { + "group": "Tutorials", + "pages": [ + "cofhe/tutorials/overview", + "cofhe/tutorials/migrating-from-fhe-decrypt", + "cofhe/tutorials/your-first-fhe-contract", + "cofhe/tutorials/adding-fhe-to-existing-contract", + "cofhe/tutorials/acl-usage-examples" + ] + } ] }, { - "group": "Research", - "pages": [ - "deep-dive/research/future-plans", - "deep-dive/research/research-in-fhenix" + "tab": "Deep Dive", + "groups": [ + { + "group": "CoFHE Components", + "pages": [ + "cofhe/deep-dive/cofhe-components/overview", + "cofhe/deep-dive/cofhe-components/task-manager", + "cofhe/deep-dive/cofhe-components/acl", + "cofhe/deep-dive/cofhe-components/plaintext-storage", + "cofhe/deep-dive/cofhe-components/commitment-registry", + "cofhe/deep-dive/cofhe-components/verify-commitments", + "cofhe/deep-dive/cofhe-components/zk-verifier", + "cofhe/deep-dive/cofhe-components/compute-pipeline", + "cofhe/deep-dive/cofhe-components/teecryptor", + "cofhe/deep-dive/cofhe-components/key-management" + ] + }, + { + "group": "Data Flows", + "pages": [ + "cofhe/deep-dive/data-flows/encryption-request-flow", + "cofhe/deep-dive/data-flows/fhe-operation-request-flow", + "cofhe/deep-dive/data-flows/decryption-request-flow" + ] + }, + { + "group": "Research", + "pages": [ + "cofhe/deep-dive/research/future-plans", + "cofhe/deep-dive/research/research-in-fhenix" + ] + } ] } ] @@ -321,103 +327,127 @@ "redirects": [ { "source": "/get-started/builder-support/get-funded", - "destination": "/get-started/introduction/support-and-feedback" + "destination": "/cofhe/get-started/introduction/support-and-feedback" }, { "source": "/docs/devdocs/overview", - "destination": "/" + "destination": "/cofhe" }, { "source": "/client-sdk/guides/permits", - "destination": "/client-sdk/guides/acps" + "destination": "/cofhe/client-sdk/guides/acps" }, { "source": "/deep-dive/cofhe-components/threshold-network", - "destination": "/deep-dive/cofhe-components/teecryptor" + "destination": "/cofhe/deep-dive/cofhe-components/teecryptor" }, { "source": "/deep-dive/cofhe-components/slim-listener", - "destination": "/deep-dive/cofhe-components/compute-pipeline" + "destination": "/cofhe/deep-dive/cofhe-components/compute-pipeline" }, { "source": "/deep-dive/cofhe-components/fheos-server", - "destination": "/deep-dive/cofhe-components/compute-pipeline" + "destination": "/cofhe/deep-dive/cofhe-components/compute-pipeline" }, { "source": "/deep-dive/cofhe-components/result-processor", - "destination": "/deep-dive/cofhe-components/compute-pipeline" + "destination": "/cofhe/deep-dive/cofhe-components/compute-pipeline" }, { "source": "/deep-dive/cofhe-components/ct-registry", - "destination": "/deep-dive/cofhe-components/commitment-registry" + "destination": "/cofhe/deep-dive/cofhe-components/commitment-registry" }, { "source": "/deep-dive/data-flows/off-chain-decryption-flow", - "destination": "/deep-dive/data-flows/decryption-request-flow" + "destination": "/cofhe/deep-dive/data-flows/decryption-request-flow" }, { "source": "/deep-dive/cofhe-components/fhe-engine", - "destination": "/deep-dive/cofhe-components/compute-pipeline" + "destination": "/cofhe/deep-dive/cofhe-components/compute-pipeline" }, { "source": "/api-reference/introduction", - "destination": "/client-sdk/reference/sdk-reference" + "destination": "/cofhe/client-sdk/reference/sdk-reference" }, { "source": "/api-reference/endpoint/get", - "destination": "/client-sdk/reference/sdk-reference" + "destination": "/cofhe/client-sdk/reference/sdk-reference" }, { "source": "/api-reference/endpoint/create", - "destination": "/client-sdk/reference/sdk-reference" + "destination": "/cofhe/client-sdk/reference/sdk-reference" }, { "source": "/api-reference/endpoint/delete", - "destination": "/client-sdk/reference/sdk-reference" + "destination": "/cofhe/client-sdk/reference/sdk-reference" }, { "source": "/api-reference/endpoint/webhook", - "destination": "/client-sdk/reference/sdk-reference" + "destination": "/cofhe/client-sdk/reference/sdk-reference" }, { "source": "/cofhejs/introduction/overview", - "destination": "/client-sdk/introduction/overview" + "destination": "/cofhe/client-sdk/introduction/overview" }, { "source": "/cofhejs/introduction/installation", - "destination": "/client-sdk/introduction/installation" + "destination": "/cofhe/client-sdk/introduction/installation" }, { "source": "/cofhejs/introduction/mental-model", - "destination": "/client-sdk/introduction/mental-model" + "destination": "/cofhe/client-sdk/introduction/mental-model" }, { "source": "/cofhejs/guides/encryption", - "destination": "/client-sdk/guides/encrypting-inputs" + "destination": "/cofhe/client-sdk/guides/encrypting-inputs" }, { "source": "/cofhejs/guides/permits-management", - "destination": "/client-sdk/guides/acps" + "destination": "/cofhe/client-sdk/guides/acps" }, { "source": "/cofhejs/guides/sealing-unsealing", - "destination": "/client-sdk/guides/decrypt-to-view" + "destination": "/cofhe/client-sdk/guides/decrypt-to-view" }, { "source": "/cofhejs/guides/error-handling", - "destination": "/client-sdk/guides/error-handling" + "destination": "/cofhe/client-sdk/guides/error-handling" }, { "source": "/cofhejs/examples/end-to-end", - "destination": "/client-sdk/examples/end-to-end" + "destination": "/cofhe/client-sdk/examples/end-to-end" }, { "source": "/cofhejs/resources/templates", - "destination": "/client-sdk/examples/templates" + "destination": "/cofhe/client-sdk/examples/templates" }, { "source": "/fhe-library/reference/fhe-sol", - "destination": "/fhe-library/reference/fhe-sol/overview" + "destination": "/cofhe/fhe-library/reference/fhe-sol/overview" + }, + { + "source": "/get-started/:slug*", + "destination": "/cofhe/get-started/:slug*" + }, + { + "source": "/client-sdk/:slug*", + "destination": "/cofhe/client-sdk/:slug*" + }, + { + "source": "/fhe-library/:slug*", + "destination": "/cofhe/fhe-library/:slug*" + }, + { + "source": "/tutorials/:slug*", + "destination": "/cofhe/tutorials/:slug*" + }, + { + "source": "/deep-dive/:slug*", + "destination": "/cofhe/deep-dive/:slug*" + }, + { + "source": "/images/:slug*", + "destination": "/cofhe/images/:slug*" } ], "integrations": { From 06f207a34fd06500dd73f48a72dd5fb2a51c8438 Mon Sep 17 00:00:00 2001 From: haim Date: Tue, 13 Oct 2026 16:29:53 +0300 Subject: [PATCH 2/5] [FEAT] Add docs landing page and Wallet Module product --- docs.json | 21 ++++++++++++++++++++- index.mdx | 40 ++++++++++++++++++++++++++++++++++++++++ wallet/index.mdx | 10 ++++++++++ 3 files changed, 70 insertions(+), 1 deletion(-) create mode 100644 index.mdx create mode 100644 wallet/index.mdx diff --git a/docs.json b/docs.json index 329debc3..cdf34e21 100644 --- a/docs.json +++ b/docs.json @@ -2,7 +2,7 @@ "$schema": "https://mintlify.com/docs.json", "theme": "mint", "name": "Fhenix Documentation", - "description": "Documentation for CoFHE, Fhenix's Fully Homomorphic Encryption coprocessor: write Solidity contracts that compute on encrypted data.", + "description": "Documentation for Fhenix products: CoFHE and the Wallet Module.", "seo": { "metatags": { "og:site_name": "Fhenix Documentation", @@ -19,6 +19,13 @@ "favicon": "/favicon.svg", "navigation": { "products": [ + { + "product": "All products", + "icon": "grid-2", + "pages": [ + "index" + ] + }, { "product": "CoFHE", "icon": "lock", @@ -288,6 +295,18 @@ ] } ] + }, + { + "product": "Wallet Module", + "icon": "wallet", + "groups": [ + { + "group": "Wallet Module", + "pages": [ + "wallet/index" + ] + } + ] } ] }, diff --git a/index.mdx b/index.mdx new file mode 100644 index 00000000..a3e70b61 --- /dev/null +++ b/index.mdx @@ -0,0 +1,40 @@ +--- +title: "Fhenix Developer Docs" +sidebarTitle: "All products" +description: "Guides, references, and tutorials for every Fhenix product." +mode: "custom" +--- + + diff --git a/wallet/index.mdx b/wallet/index.mdx new file mode 100644 index 00000000..ebbb0fb9 --- /dev/null +++ b/wallet/index.mdx @@ -0,0 +1,10 @@ +--- +title: "Wallet Module" +description: "Documentation for the Fhenix Wallet Module is coming soon." +--- + +## Coming soon + +The Wallet Module documentation is in progress. + +For encrypted computation on Fhenix today, see the [CoFHE documentation](/cofhe). From 322bb8d8fe2e39f829057a8247ba9cde9beffd24 Mon Sep 17 00:00:00 2001 From: haim Date: Tue, 13 Oct 2026 16:33:47 +0300 Subject: [PATCH 3/5] [DOCS] Split shared and per-product agent docs and style guide --- .mintignore | 10 ++++ AGENTS.md | 37 ++++-------- CLAUDE.md | 45 +++++++++----- README.md | 42 +++++++------ RELEASE-CHECKLIST.md | 4 +- STYLE.md | 90 +++------------------------- cofhe/AGENTS.md | 26 +++++++++ cofhe/CLAUDE.md | 26 +++++++++ cofhe/STYLE-cofhe.md | 91 +++++++++++++++++++++++++++++ styles/Fhenix/Condescending.yml | 2 +- styles/Fhenix/DecorativeUnicode.yml | 2 +- styles/Fhenix/EmDash.yml | 2 +- styles/Fhenix/Exclamation.yml | 2 +- styles/Fhenix/Filler.yml | 2 +- styles/Fhenix/FutureTense.yml | 2 +- styles/Fhenix/Headings.yml | 2 +- styles/Fhenix/Idioms.yml | 2 +- styles/Fhenix/InternalNames.yml | 2 +- styles/Fhenix/LinkText.yml | 2 +- styles/Fhenix/Marketing.yml | 2 +- styles/Fhenix/SentenceLength.yml | 2 +- styles/Fhenix/SmartQuotes.yml | 2 +- styles/Fhenix/Terms.yml | 2 +- wallet/AGENTS.md | 14 +++++ wallet/CLAUDE.md | 14 +++++ 25 files changed, 265 insertions(+), 162 deletions(-) create mode 100644 .mintignore create mode 100644 cofhe/AGENTS.md create mode 100644 cofhe/CLAUDE.md create mode 100644 cofhe/STYLE-cofhe.md create mode 100644 wallet/AGENTS.md create mode 100644 wallet/CLAUDE.md diff --git a/.mintignore b/.mintignore new file mode 100644 index 00000000..f0531c2c --- /dev/null +++ b/.mintignore @@ -0,0 +1,10 @@ +AGENTS.md +CLAUDE.md +STYLE.md +**/AGENTS.md +**/CLAUDE.md +**/STYLE-*.md +RELEASE-CHECKLIST.md +local/ +scripts/ +cofhe/scripts/ diff --git a/AGENTS.md b/AGENTS.md index 47ba5f47..4440c6d6 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,27 +1,23 @@ -# Working on the CoFHE docs +# Working on the Fhenix docs -This repo is the Mintlify site behind cofhe-docs.fhenix.zone. It documents the live CoFHE system for external developers. +This repo is the Mintlify site behind docs.fhenix.io. Each product lives in its own folder (`cofhe/`, `wallet/`) and has its own `AGENTS.md` with product facts. Read both: the rules here apply to every product. -## The one rule that matters - -STYLE.md is binding for all content. Read it before writing or editing any page. If a page you touch conflicts with STYLE.md, fix the page. +- `/` is the landing page (`index.mdx`), with one card per product. +- Product pages live under their folder and their URL prefix: `cofhe/...` is served at `/cofhe/...`. -## Facts +## The one rule that matters -- Never write a technical claim you have not verified against the current source of the relevant repo (cofhe, cofhesdk, teecryptor, zee-k-verifier, fhenix-confidential-contracts) or the published packages. Docs drift is the failure mode this project exists to fix. -- For the confidential token contracts (FHERC20, ERC20Confidential, the wrappers), verify against the Solidity under `contracts/` at the tag matching the version on the compatibility page, or the published npm package. The repo README lags the code; do not take API shapes from it. -- Current behavior and future plans never mix. Future work lives in `deep-dive/research/future-plans.mdx`, labeled as such. -- The TEE (Teecryptor) is the current decryption architecture. The Threshold Network is a future plan only. -- No internal names: hostnames, cloud project names, environment names, deployment bundle names, feature flags. +STYLE.md is binding for all content. Each product adds its own terms and diagram rules in its folder (for CoFHE: `cofhe/STYLE-cofhe.md`). Read it before writing or editing any page. If a page you touch conflicts with STYLE.md, fix the page. ## Mechanics -- Navigation lives in `docs.json`. A page not referenced there is invisible; check it when adding, renaming, or removing pages. +- Navigation lives in `docs.json`, under `navigation.products`: one product per folder. A page not referenced there is invisible; check it when adding, renaming, or removing pages. - Renaming or removing a page requires a redirect entry. -- Diagrams are Mermaid blocks in the page (see STYLE.md, Diagrams). Sequence diagrams use the fixed lane order and zone bands in STYLE.md, "Sequence diagram lanes". Do not add or edit SVGs; designed SVGs come from the design pass and keep their Mermaid source in the repo. +- Diagrams are Mermaid blocks in the page (see STYLE.md, Diagrams). Each product sets its diagram lanes and colors in its own style file (for CoFHE: `cofhe/STYLE-cofhe.md`, "Sequence diagram lanes"). Do not add or edit SVGs; designed SVGs come from the design pass and keep their Mermaid source in the repo. - Code samples must compile or run against the currently published versions before they ship. +- Product CI runs only on its folder: a workflow for one product filters on `paths: /**`. Shared checks (`Docs style`, `Mint check`) run on every product. - Mintlify renders the page H1 from the frontmatter `title`. Body headings start at `##` and never skip a level. -- Internal links are root-relative: `/fhe-library/core-concepts/access-control`, never `../` and never the full site URL. +- Internal links are root-relative: `/cofhe/fhe-library/core-concepts/access-control`, never `../` and never the full site URL. ## Linters @@ -40,19 +36,8 @@ The `Docs style` action runs both on the `.mdx` files a pull request touches. Er Neither linter can tell whether a claim is true. That stays your job. -## Samples - -The `Sample compile` action compiles every ```solidity block on the pages a pull request touches, with forge, against the `@fhenixprotocol/cofhe-contracts` and `fhenix-confidential-contracts` versions pinned in `.github/workflows/sample-compile.yml`. A complete contract that fails blocks the merge; a fragment that fails only warns. Run it locally before opening a pull request: - -```bash -npm install --no-save @fhenixprotocol/cofhe-contracts@0.2.0 fhenix-confidential-contracts@0.4.0 -python3 scripts/compile-samples.py $FILES -``` - -Those pins follow the compatibility page. When it changes, move them too; `python3 scripts/check-versions.py --docs` fails until you do. The action does not deploy or run anything, so a sample that compiles can still be wrong. Library linking, for example, only fails at deploy time. - ## Workflow -- Work is tracked in the Jira DOC project, one epic per site tab. Ticket summaries start with `[page-slug]`. +- Each product says in its own `AGENTS.md` where its docs work is tracked. - Commit messages: single line, `[DOCS] /: summary`. - One page per commit on rewrite branches, so commits can be cherry-picked individually. diff --git a/CLAUDE.md b/CLAUDE.md index 76d05333..4440c6d6 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,28 +1,43 @@ -# Working on the CoFHE docs +# Working on the Fhenix docs -This repo is the Mintlify site behind cofhe-docs.fhenix.zone. It documents the live CoFHE system for external developers. +This repo is the Mintlify site behind docs.fhenix.io. Each product lives in its own folder (`cofhe/`, `wallet/`) and has its own `AGENTS.md` with product facts. Read both: the rules here apply to every product. -## The one rule that matters - -STYLE.md is binding for all content. Read it before writing or editing any page. If a page you touch conflicts with STYLE.md, fix the page. +- `/` is the landing page (`index.mdx`), with one card per product. +- Product pages live under their folder and their URL prefix: `cofhe/...` is served at `/cofhe/...`. -## Facts +## The one rule that matters -- Never write a technical claim you have not verified against the current source of the relevant repo (cofhe, cofhesdk, teecryptor, zee-k-verifier, fhenix-confidential-contracts) or the published packages. Docs drift is the failure mode this project exists to fix. -- For the confidential token contracts (FHERC20, ERC20Confidential, the wrappers), verify against the Solidity under `contracts/` at the tag matching the version on the compatibility page, or the published npm package. The repo README lags the code; do not take API shapes from it. -- Current behavior and future plans never mix. Future work lives in `deep-dive/research/future-plans.mdx`, labeled as such. -- The TEE (Teecryptor) is the current decryption architecture. The Threshold Network is a future plan only. -- No internal names: hostnames, cloud project names, environment names, deployment bundle names, feature flags. +STYLE.md is binding for all content. Each product adds its own terms and diagram rules in its folder (for CoFHE: `cofhe/STYLE-cofhe.md`). Read it before writing or editing any page. If a page you touch conflicts with STYLE.md, fix the page. ## Mechanics -- Navigation lives in `docs.json`. A page not referenced there is invisible; check it when adding, renaming, or removing pages. +- Navigation lives in `docs.json`, under `navigation.products`: one product per folder. A page not referenced there is invisible; check it when adding, renaming, or removing pages. - Renaming or removing a page requires a redirect entry. -- Diagrams are Mermaid blocks in the page (see STYLE.md, Diagrams). Do not add or edit SVGs; designed SVGs come from the design pass and keep their Mermaid source in the repo. -- Code samples must compile or run against the currently published versions before they ship. `scripts/compile-samples.py` compiles the Solidity ones; see AGENTS.md, Samples. +- Diagrams are Mermaid blocks in the page (see STYLE.md, Diagrams). Each product sets its diagram lanes and colors in its own style file (for CoFHE: `cofhe/STYLE-cofhe.md`, "Sequence diagram lanes"). Do not add or edit SVGs; designed SVGs come from the design pass and keep their Mermaid source in the repo. +- Code samples must compile or run against the currently published versions before they ship. +- Product CI runs only on its folder: a workflow for one product filters on `paths: /**`. Shared checks (`Docs style`, `Mint check`) run on every product. +- Mintlify renders the page H1 from the frontmatter `title`. Body headings start at `##` and never skip a level. +- Internal links are root-relative: `/cofhe/fhe-library/core-concepts/access-control`, never `../` and never the full site URL. + +## Linters + +Two linters enforce the mechanical half of STYLE.md. Run both on what you changed before opening a pull request: + +```bash +FILES=$(git diff --name-only --diff-filter=d origin/main...HEAD -- '*.mdx') +python3 scripts/lint-docs.py $FILES +vale $FILES +``` + +- `vale` covers prose: em dashes, decorative Unicode, filler, marketing adjectives, "simply" and "easy", idioms, terminology, Title Case headings. Rules live in `styles/Fhenix/`. +- `scripts/lint-docs.py` covers structure: frontmatter, manual H1 headings, skipped heading levels, code blocks with no language tag, link paths, alt text. + +The `Docs style` action runs both on the `.mdx` files a pull request touches. Errors block the merge, warnings do not. Pages written before the linters existed still contain violations, so the action ignores files your branch did not touch. Fix a legacy page when you are already editing it, not in a sweep. + +Neither linter can tell whether a claim is true. That stays your job. ## Workflow -- Work is tracked in the Jira DOC project, one epic per site tab. Ticket summaries start with `[page-slug]`. +- Each product says in its own `AGENTS.md` where its docs work is tracked. - Commit messages: single line, `[DOCS] /: summary`. - One page per commit on rewrite branches, so commits can be cherry-picked individually. diff --git a/README.md b/README.md index c2a0502a..70809a26 100644 --- a/README.md +++ b/README.md @@ -1,16 +1,9 @@ # Fhenix Developer Documentation -Official documentation for Fhenix - the privacy-preserving blockchain platform that enables developers to build confidential smart contracts using Fully Homomorphic Encryption (FHE). +The documentation for Fhenix products, served at [docs.fhenix.io](https://docs.fhenix.io). -## About This Documentation - -This repository contains the complete developer documentation for Fhenix, including: - -- **Get Started** - Introduction to Fhenix and CoFHE, compatibility, support, and builder programs -- **Client SDK** - `@cofhe/sdk` for encrypting inputs, managing Access Control Permissions, and decrypting outputs, plus the Hardhat and Foundry plugins -- **FHE library** - `FHE.sol`, the Solidity library for working with encrypted data in smart contracts -- **Tutorials** - Step-by-step guides for building FHE-enabled applications -- **Deep Dive** - Technical architecture details, CoFHE components, and data flows +- **CoFHE** (`cofhe/`): the FHE coprocessor. Write Solidity contracts that compute on encrypted data. Covers Get Started, the Client SDK, the FHE library, Tutorials, and the Deep Dive. +- **Wallet Module** (`wallet/`): coming soon. ## Development @@ -37,19 +30,24 @@ The documentation will be available at `http://localhost:3000`. ## Project Structure ``` -fhenix-developer-docs/ -├── get-started/ # Introduction and getting started guides -├── client-sdk/ # @cofhe/sdk, Hardhat plugin, and Foundry plugin docs -├── fhe-library/ # Solidity FHE library documentation -├── tutorials/ # Step-by-step tutorials -├── deep-dive/ # Architecture and technical deep dives -├── images/ # Images referenced from pages -├── scripts/ # Structure linter (lint-docs.py) -├── styles/ # Vale prose rules +fhenix-docs/ +├── index.mdx # Landing page, one card per product +├── cofhe/ # CoFHE docs, served at /cofhe +│ ├── get-started/ client-sdk/ fhe-library/ tutorials/ deep-dive/ +│ ├── images/ +│ ├── scripts/ # CoFHE checks: versions, sample compile +│ ├── AGENTS.md # CoFHE facts for contributors and agents +│ └── STYLE-cofhe.md # CoFHE terms and diagram rules +├── wallet/ # Wallet Module docs, served at /wallet +├── scripts/ # Shared structure linter (lint-docs.py) +├── styles/ # Shared Vale prose rules ├── STYLE.md # Writing style guide, binding for all pages -└── docs.json # Mintlify configuration +├── AGENTS.md # Shared rules for contributors and agents +└── docs.json # Mintlify configuration: products, navigation, redirects ``` +To add a product, create its folder, add it to `navigation.products` in `docs.json`, and add a card to `index.mdx`. + ## Publishing Changes Changes pushed to the default branch are automatically deployed to production through the Mintlify GitHub app integration. @@ -80,11 +78,11 @@ We welcome contributions to improve the documentation. When making changes: ## Resources - [Mintlify Documentation](https://mintlify.com/docs) -- [CoFHE documentation live site](https://cofhe-docs.fhenix.zone) +- [Fhenix documentation live site](https://docs.fhenix.io) ## Support For questions and support: - Join our [Telegram Support Channel](https://t.me/+OEO4CItQYh8xYzNh) - Visit our [Discord](https://discord.com/invite/FuVgxrvJMY) -- Check the [Support and Feedback](get-started/introduction/support-and-feedback.mdx) documentation +- Check the [Support and Feedback](cofhe/get-started/introduction/support-and-feedback.mdx) documentation diff --git a/RELEASE-CHECKLIST.md b/RELEASE-CHECKLIST.md index ecfa3cbf..cf87b0aa 100644 --- a/RELEASE-CHECKLIST.md +++ b/RELEASE-CHECKLIST.md @@ -1,4 +1,4 @@ -# Docs pass per release +# CoFHE docs pass per release Every release of cofhe, cofhe-contracts, cofhesdk, teecryptor, or zee-k-verifier requires this pass before the release announcement. The release owner opens one DOC ticket per release and links it to the release. @@ -7,7 +7,7 @@ Every release of cofhe, cofhe-contracts, cofhesdk, teecryptor, or zee-k-verifier 1. Read the release changelog. List every change to a public surface: contract API, SDK API, wire fields, endpoints, error names, component names. 2. Map each change to its pages. Start from the Deep Dive component page, then the data flows, then guides and tutorials that name the surface. 3. Update the pages. Verify every claim against the released source, not the changelog text. -4. Update `get-started/introduction/compatibility.mdx` when a package version changed. +4. Update `cofhe/get-started/introduction/compatibility.mdx` when a package version changed. 5. Run the checks: `vale ` and `python3 scripts/lint-docs.py `. CI runs link and sample checks on the PR. 6. Diagrams: when a component or flow changed, update the page `.mmd` source and re-run the archify build for that diagram. 7. Open one PR per release, one page per commit. Merge before the release announcement goes out. diff --git a/STYLE.md b/STYLE.md index 0b9a0b28..722090bb 100644 --- a/STYLE.md +++ b/STYLE.md @@ -1,6 +1,6 @@ # Documentation Style Guide -This guide defines how we write content for cofhe-docs.fhenix.zone. It covers language only, not visual design. Every page, new or rewritten, should follow it. When an existing page conflicts with this guide, the guide wins. +This guide defines how we write content for docs.fhenix.io. It covers language only, not visual design. Every page, new or rewritten, should follow it. When an existing page conflicts with this guide, the guide wins. The goal: docs that read like they were written by an engineer who understands the system and respects the reader's time. Our readers are developers with sharp eyes. They notice filler, they notice hedging, and they notice text that no human would write. @@ -57,25 +57,7 @@ Write like an engineer explaining a system to another engineer: not an academic Define a term at its first use on a page, in a short parenthetical or half sentence, even when a glossary page exists. Readers land on pages from search; no page gets to assume the reader arrived in order. -One name per thing, used consistently. Canonical names: - -| Term | Notes | -|---|---| -| CoFHE | The coprocessor as a whole. Not COFHE, not Cofhe. | -| Teecryptor | The TEE decryption component. Capitalized as a product name. | -| Compute pipeline | The offchain pipeline that carries a task from onchain event to committed result. Lowercase, except at the start of a sentence. | -| Slim listener, FheOS, FHE Engine, Blockchain poster | The four components of the compute pipeline, in order. FHE Engine names the component that computes, never the pipeline around it. | -| ZK Verifier | The TEE input proof verification component. Runs in its own attested enclave, like Teecryptor. | -| CT Server | The component that stores and serves ciphertext bytes. Use this name in diagram lanes. In prose, "ciphertext store" names the database behind it. | -| TaskManager, CommitmentRegistry, ACL | Contract names, written as in the source. | -| ACP | Access Control Permission. Replaces "Permit" from `0.7` onward, so that it is not confused with an ERC-2612 permit. Spell it out before the acronym: a page whose subject is ACPs carries the full term in its `title`, and every other page expands it on first use. Never write "ACP permission". | -| `FHE.sol` | The Solidity library, in backticks when referring to the file or API. | -| `@cofhe/sdk` | The client SDK package, in backticks. "the SDK" after first mention on a page. | -| Threshold Network | The future MPC decryption network. Always framed as planned, never as current. | -| onchain, offchain | One word, no hyphen. | -| ciphertext, plaintext | One word. | -| handle | A reference to an encrypted value held by a contract. Do not mix with "hash" in prose; `ctHash` appears only as the code identifier. | -| testnet, mainnet | Lowercase. | +Each product keeps its own table of canonical names in its folder. CoFHE terminology lives in `cofhe/STYLE-cofhe.md`. Do not use internal names in public docs: no hostnames, no GCP project names, no environment names (staging, rehearsal), no deployment bundle names like "aggregator", and no internal feature flags. @@ -99,8 +81,8 @@ Do not use internal names in public docs: no hostnames, no GCP project names, no ## Links, images, and components -- Internal links use root-relative paths: `/fhe-library/core-concepts/access-control`, not `../core-concepts/access-control` and not the full `https://cofhe-docs.fhenix.zone/...` URL. Relative paths break when a page moves; absolute URLs break preview deployments. -- Link text describes the destination. "See [access control](/fhe-library/core-concepts/access-control)", never `"click [here](/...)"` or a bare URL. +- Internal links use root-relative paths: `/cofhe/fhe-library/core-concepts/access-control`, not `../core-concepts/access-control` and not the full `https://docs.fhenix.io/...` URL. Relative paths break when a page moves; absolute URLs break preview deployments. +- Link text describes the destination. "See [access control](/cofhe/fhe-library/core-concepts/access-control)", never `"click [here](/...)"` or a bare URL. - Never link to a private repository; readers get a 404. Of the FhenixProtocol repos, `cofhe-contracts`, `cofhesdk`, `teecryptor`, `zee-k-verifier`, `cofhe-tdx-keygen`, and `fhenix-confidential-contracts` are public. Name a component or path in prose instead, and add the link when the repo goes public. - A designed diagram declares a width past the content column, around 1440px, with the viewBox left at its own size. `` centres an image at its intrinsic size on its own backdrop and drops inline styles, so a narrower diagram sits letterboxed. The vector scales, so oversizing the declaration costs nothing. - Every image is wrapped in `` and carries alt text that says what the image shows, not what it is called. "Sealed output flowing from the FHE Engine to the client", not "diagram". @@ -137,70 +119,12 @@ A page full of callouts has none. - Mermaid is the source of truth for every diagram. It lives in the page as a ```mermaid block, renders natively on the site, and diffs like text in review. - A designed SVG is an optional finalization step, not the source. When one replaces a rendered Mermaid block, the Mermaid source stays in the repo next to it, and any later change to the flow updates the Mermaid first. -- Actor names in diagrams use the canonical terminology above and must match the page text exactly. +- Actor names in diagrams use the canonical terminology of the product (see its style file) and must match the page text exactly. - A diagram shows one flow. If it needs a legend to be understood, split it. -### Sequence diagram lanes - -Every sequence diagram draws its columns from one list of components, in one order. A page picks the components its flow needs. It never reorders them and never renames them. A reader who has followed one flow can then read any other without relearning the columns. - -| Slot | Component | -|---|---| -| 1 | Your app | -| 2 | Client SDK | -| 3 | Your contract | -| 4 | TaskManager | -| 5 | ZK Verifier, Compute pipeline, Teecryptor | -| 6 | CommitmentRegistry | - -Slot 5 holds the component the page is about. A flow that needs more than one keeps them in the order above, which is the order a value meets them: verified as an input, computed, then decrypted. - -**CommitmentRegistry** is the one column every request flow has in common, because every ciphertext is anchored there. **TaskManager** is in every flow that touches the host chain. Keep both visible wherever the flow reaches them, and let the rest of the columns be subset-specific. Do not add a column to a diagram only to make it match another one. - -An intro page may collapse the CoFHE components into a single column named CoFHE, and may show the chain itself as Host chain. A reader meeting the system for the first time does not need nine components to follow the story. Every other column still uses its canonical name. - -A column that the flow really touches, but that is drawn idle, reads as a column the flow does not touch, which is a different and false claim. So a component is either a column everywhere it appears, or it is not a column at all. - -CT Server is the deliberate second case. It stores and serves ciphertext bytes for the ZK Verifier and Teecryptor, but on most pages it carries a single round trip, and a whole column for that crowds the diagram. It is drawn as a self-message on the component that calls it, and the message names it, so the reader still learns who serves the bytes. The FHE Engine is different again: it writes the ciphertext store directly, so its message names no component. - -Never declare a column the flow does not use. Mermaid draws it at full strength with no messages, and a reader takes that for a mistake. Mermaid also cannot dim a single column, so there is no way to show one as inactive: leave it out instead. +### Product diagram rules -### Diagram color - -Color marks **where a component runs**, never what kind of component it is. A reader should be able to answer "is this mine, is this onchain, is this Fhenix's" from the color alone, and get the same answer on every page. - -| Zone | Components | Color | -|---|---|---| -| Client side, and independent parties | Your app, Client SDK, Partners | `#0466A2` | -| Host chain | Your contract, TaskManager | `#F37A49` | -| CoFHE, offchain | ZK Verifier, Compute pipeline, Teecryptor | `#0AD9DC` | -| Registry chain | CommitmentRegistry | `#BF90F8` | - -The dark ground is `#122531`. These values live in the export script, not in each -diagram, so one edit changes every diagram. - -CT Server is not in the table because it is never a column; it is named inside a self-message. Components in one zone share one color, including those a given flow does not use. Teecryptor is the same color on the decryption pages as the ZK Verifier is on the encryption page, because both run offchain inside CoFHE. A component must never change color between diagrams. - -The reader-facing key is the page's own "Key components" table, which carries a **Runs in** column naming each component's zone. That is the legend: no swatches, no hex values in prose, and nothing to drift when a preset changes. A page that has such a table carries the column; a page without one names the zones in the tip under its diagram instead. - -Do not color by component type. That is the tool's default, and it produces one accent per participant, encoding a distinction the reader cannot act on. - -Architecture and lifecycle diagrams name their legend entries after the renderer's own component or state kinds, which say nothing a reader can use: a contract labelled "Database", a deliberate end state labelled "failure". Relabel those entries to the zone or the state's real meaning. Sequence legends describe arrow kinds and already read correctly. - -The key management ceremony sits outside this table, like its actors: the keygen ceremony and the component enclave run inside CoFHE, but the partners are independent custodians and must not read as CoFHE's. - -One action gets one phrase, in every diagram that shows it: - -| Action | Phrase | -|---|---| -| ACL check | `isAllowedWithPermission / isPubliclyAllowed` | -| Commitment read | `getCommitment(version, handle)` | -| Commitment write | `postCommitments (batched)` | -| Ciphertext read | `fetch the ciphertext from CT Server` | -| Ciphertext write | `store the ciphertext bytes in CT Server` | -| Engine ciphertext write | `store the ciphertext under the handle` | - -Diagrams that are not request flows keep their own actors. The key management ceremony and the compute pipeline's internal structure have no counterpart in the table above, and forcing them into it would say something untrue. +Each product keeps its own diagram lanes and colors in its folder. CoFHE lanes and colors live in `cofhe/STYLE-cofhe.md`. ## Enforcement diff --git a/cofhe/AGENTS.md b/cofhe/AGENTS.md new file mode 100644 index 00000000..4d3a1051 --- /dev/null +++ b/cofhe/AGENTS.md @@ -0,0 +1,26 @@ +# CoFHE docs + +Pages under `cofhe/` document CoFHE, served at `/cofhe/...`. The root `AGENTS.md` and `STYLE.md` apply here too. `cofhe/STYLE-cofhe.md` adds the CoFHE terms and diagram rules. + +## Facts + +- Never write a technical claim you have not verified against the current source of the relevant repo (cofhe, cofhesdk, teecryptor, zee-k-verifier, fhenix-confidential-contracts) or the published packages. Docs drift is the failure mode this project exists to fix. +- For the confidential token contracts (FHERC20, ERC20Confidential, the wrappers), verify against the Solidity under `contracts/` at the tag matching the version on the compatibility page, or the published npm package. The repo README lags the code; do not take API shapes from it. +- Current behavior and future plans never mix. Future work lives in `cofhe/deep-dive/research/future-plans.mdx`, labeled as such. +- The TEE (Teecryptor) is the current decryption architecture. The Threshold Network is a future plan only. +- No internal names: hostnames, cloud project names, environment names, deployment bundle names, feature flags. + +## Samples + +The `Sample compile` action compiles every ```solidity block on the pages a pull request touches, with forge, against the `@fhenixprotocol/cofhe-contracts` and `fhenix-confidential-contracts` versions pinned in `.github/workflows/sample-compile.yml`. A complete contract that fails blocks the merge; a fragment that fails only warns. Run it locally before opening a pull request: + +```bash +npm install --no-save @fhenixprotocol/cofhe-contracts@1.0.0 fhenix-confidential-contracts@0.4.0 +python3 cofhe/scripts/compile-samples.py $FILES +``` + +Those pins must match `COFHE_CONTRACTS_VERSION` and `CONFIDENTIAL_CONTRACTS_VERSION` in `.github/workflows/sample-compile.yml`, which follow the compatibility page. When it changes, move them too; `python3 cofhe/scripts/check-versions.py --docs` fails until you do. The action does not deploy or run anything, so a sample that compiles can still be wrong. Library linking, for example, only fails at deploy time. + +## Workflow + +- CoFHE docs work is tracked in the Jira DOC project, one epic per site tab. Ticket summaries start with `[page-slug]`. diff --git a/cofhe/CLAUDE.md b/cofhe/CLAUDE.md new file mode 100644 index 00000000..4d3a1051 --- /dev/null +++ b/cofhe/CLAUDE.md @@ -0,0 +1,26 @@ +# CoFHE docs + +Pages under `cofhe/` document CoFHE, served at `/cofhe/...`. The root `AGENTS.md` and `STYLE.md` apply here too. `cofhe/STYLE-cofhe.md` adds the CoFHE terms and diagram rules. + +## Facts + +- Never write a technical claim you have not verified against the current source of the relevant repo (cofhe, cofhesdk, teecryptor, zee-k-verifier, fhenix-confidential-contracts) or the published packages. Docs drift is the failure mode this project exists to fix. +- For the confidential token contracts (FHERC20, ERC20Confidential, the wrappers), verify against the Solidity under `contracts/` at the tag matching the version on the compatibility page, or the published npm package. The repo README lags the code; do not take API shapes from it. +- Current behavior and future plans never mix. Future work lives in `cofhe/deep-dive/research/future-plans.mdx`, labeled as such. +- The TEE (Teecryptor) is the current decryption architecture. The Threshold Network is a future plan only. +- No internal names: hostnames, cloud project names, environment names, deployment bundle names, feature flags. + +## Samples + +The `Sample compile` action compiles every ```solidity block on the pages a pull request touches, with forge, against the `@fhenixprotocol/cofhe-contracts` and `fhenix-confidential-contracts` versions pinned in `.github/workflows/sample-compile.yml`. A complete contract that fails blocks the merge; a fragment that fails only warns. Run it locally before opening a pull request: + +```bash +npm install --no-save @fhenixprotocol/cofhe-contracts@1.0.0 fhenix-confidential-contracts@0.4.0 +python3 cofhe/scripts/compile-samples.py $FILES +``` + +Those pins must match `COFHE_CONTRACTS_VERSION` and `CONFIDENTIAL_CONTRACTS_VERSION` in `.github/workflows/sample-compile.yml`, which follow the compatibility page. When it changes, move them too; `python3 cofhe/scripts/check-versions.py --docs` fails until you do. The action does not deploy or run anything, so a sample that compiles can still be wrong. Library linking, for example, only fails at deploy time. + +## Workflow + +- CoFHE docs work is tracked in the Jira DOC project, one epic per site tab. Ticket summaries start with `[page-slug]`. diff --git a/cofhe/STYLE-cofhe.md b/cofhe/STYLE-cofhe.md new file mode 100644 index 00000000..0e211e24 --- /dev/null +++ b/cofhe/STYLE-cofhe.md @@ -0,0 +1,91 @@ +# CoFHE style additions + +These rules add to the root `STYLE.md` for pages under `cofhe/`. The root guide covers language. This file covers CoFHE names and diagrams. + +## Terminology + +Define a term at its first use on a page, in a short parenthetical or half sentence, even when a glossary page exists. Readers land on pages from search; no page gets to assume the reader arrived in order. + +One name per thing, used consistently. Canonical names: + +| Term | Notes | +|---|---| +| CoFHE | The coprocessor as a whole. Not COFHE, not Cofhe. | +| Teecryptor | The TEE decryption component. Capitalized as a product name. | +| Compute pipeline | The offchain pipeline that carries a task from onchain event to committed result. Lowercase, except at the start of a sentence. | +| Slim listener, FheOS, FHE Engine, Blockchain poster | The four components of the compute pipeline, in order. FHE Engine names the component that computes, never the pipeline around it. | +| ZK Verifier | The TEE input proof verification component. Runs in its own attested enclave, like Teecryptor. | +| CT Server | The component that stores and serves ciphertext bytes. Use this name in diagram lanes. In prose, "ciphertext store" names the database behind it. | +| TaskManager, CommitmentRegistry, ACL | Contract names, written as in the source. | +| ACP | Access Control Permission. Replaces "Permit" from `0.7` onward, so that it is not confused with an ERC-2612 permit. Spell it out before the acronym: a page whose subject is ACPs carries the full term in its `title`, and every other page expands it on first use. Never write "ACP permission". | +| `FHE.sol` | The Solidity library, in backticks when referring to the file or API. | +| `@cofhe/sdk` | The client SDK package, in backticks. "the SDK" after first mention on a page. | +| Threshold Network | The future MPC decryption network. Always framed as planned, never as current. | +| onchain, offchain | One word, no hyphen. | +| ciphertext, plaintext | One word. | +| handle | A reference to an encrypted value held by a contract. Do not mix with "hash" in prose; `ctHash` appears only as the code identifier. | +| testnet, mainnet | Lowercase. | + +## Diagrams + +### Sequence diagram lanes + +Every sequence diagram draws its columns from one list of components, in one order. A page picks the components its flow needs. It never reorders them and never renames them. A reader who has followed one flow can then read any other without relearning the columns. + +| Slot | Component | +|---|---| +| 1 | Your app | +| 2 | Client SDK | +| 3 | Your contract | +| 4 | TaskManager | +| 5 | ZK Verifier, Compute pipeline, Teecryptor | +| 6 | CommitmentRegistry | + +Slot 5 holds the component the page is about. A flow that needs more than one keeps them in the order above, which is the order a value meets them: verified as an input, computed, then decrypted. + +**CommitmentRegistry** is the one column every request flow has in common, because every ciphertext is anchored there. **TaskManager** is in every flow that touches the host chain. Keep both visible wherever the flow reaches them, and let the rest of the columns be subset-specific. Do not add a column to a diagram only to make it match another one. + +An intro page may collapse the CoFHE components into a single column named CoFHE, and may show the chain itself as Host chain. A reader meeting the system for the first time does not need nine components to follow the story. Every other column still uses its canonical name. + +A column that the flow really touches, but that is drawn idle, reads as a column the flow does not touch, which is a different and false claim. So a component is either a column everywhere it appears, or it is not a column at all. + +CT Server is the deliberate second case. It stores and serves ciphertext bytes for the ZK Verifier and Teecryptor, but on most pages it carries a single round trip, and a whole column for that crowds the diagram. It is drawn as a self-message on the component that calls it, and the message names it, so the reader still learns who serves the bytes. The FHE Engine is different again: it writes the ciphertext store directly, so its message names no component. + +Never declare a column the flow does not use. Mermaid draws it at full strength with no messages, and a reader takes that for a mistake. Mermaid also cannot dim a single column, so there is no way to show one as inactive: leave it out instead. + +### Diagram color + +Color marks **where a component runs**, never what kind of component it is. A reader should be able to answer "is this mine, is this onchain, is this Fhenix's" from the color alone, and get the same answer on every page. + +| Zone | Components | Color | +|---|---|---| +| Client side, and independent parties | Your app, Client SDK, Partners | `#0466A2` | +| Host chain | Your contract, TaskManager | `#F37A49` | +| CoFHE, offchain | ZK Verifier, Compute pipeline, Teecryptor | `#0AD9DC` | +| Registry chain | CommitmentRegistry | `#BF90F8` | + +The dark ground is `#122531`. These values live in the export script, not in each +diagram, so one edit changes every diagram. + +CT Server is not in the table because it is never a column; it is named inside a self-message. Components in one zone share one color, including those a given flow does not use. Teecryptor is the same color on the decryption pages as the ZK Verifier is on the encryption page, because both run offchain inside CoFHE. A component must never change color between diagrams. + +The reader-facing key is the page's own "Key components" table, which carries a **Runs in** column naming each component's zone. That is the legend: no swatches, no hex values in prose, and nothing to drift when a preset changes. A page that has such a table carries the column; a page without one names the zones in the tip under its diagram instead. + +Do not color by component type. That is the tool's default, and it produces one accent per participant, encoding a distinction the reader cannot act on. + +Architecture and lifecycle diagrams name their legend entries after the renderer's own component or state kinds, which say nothing a reader can use: a contract labelled "Database", a deliberate end state labelled "failure". Relabel those entries to the zone or the state's real meaning. Sequence legends describe arrow kinds and already read correctly. + +The key management ceremony sits outside this table, like its actors: the keygen ceremony and the component enclave run inside CoFHE, but the partners are independent custodians and must not read as CoFHE's. + +One action gets one phrase, in every diagram that shows it: + +| Action | Phrase | +|---|---| +| ACL check | `isAllowedWithPermission / isPubliclyAllowed` | +| Commitment read | `getCommitment(version, handle)` | +| Commitment write | `postCommitments (batched)` | +| Ciphertext read | `fetch the ciphertext from CT Server` | +| Ciphertext write | `store the ciphertext bytes in CT Server` | +| Engine ciphertext write | `store the ciphertext under the handle` | + +Diagrams that are not request flows keep their own actors. The key management ceremony and the compute pipeline's internal structure have no counterpart in the table above, and forcing them into it would say something untrue. diff --git a/styles/Fhenix/Condescending.yml b/styles/Fhenix/Condescending.yml index 0f6fe3c2..2a8c8c91 100644 --- a/styles/Fhenix/Condescending.yml +++ b/styles/Fhenix/Condescending.yml @@ -1,6 +1,6 @@ extends: existence message: "Avoid '%s'. If the reader is stuck, the word is an insult; if not, it is noise." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#words +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#words level: warning ignorecase: true tokens: diff --git a/styles/Fhenix/DecorativeUnicode.yml b/styles/Fhenix/DecorativeUnicode.yml index 3f8bf4d9..fc69755b 100644 --- a/styles/Fhenix/DecorativeUnicode.yml +++ b/styles/Fhenix/DecorativeUnicode.yml @@ -1,6 +1,6 @@ extends: existence message: "No decorative Unicode ('%s'). Use words: 'Shipped', 'In progress', 'Planned'." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#punctuation-and-symbols +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#punctuation-and-symbols level: error nonword: true tokens: diff --git a/styles/Fhenix/EmDash.yml b/styles/Fhenix/EmDash.yml index edbd126c..4f8b3e17 100644 --- a/styles/Fhenix/EmDash.yml +++ b/styles/Fhenix/EmDash.yml @@ -1,6 +1,6 @@ extends: existence message: "No em dashes. Rewrite with a comma, a period, a colon, or parentheses." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#punctuation-and-symbols +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#punctuation-and-symbols level: error nonword: true tokens: diff --git a/styles/Fhenix/Exclamation.yml b/styles/Fhenix/Exclamation.yml index 44e63693..bef52d84 100644 --- a/styles/Fhenix/Exclamation.yml +++ b/styles/Fhenix/Exclamation.yml @@ -1,6 +1,6 @@ extends: existence message: "Exclamation mark. At most one per tab, preferably zero." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#punctuation-and-symbols +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#punctuation-and-symbols level: warning nonword: true tokens: diff --git a/styles/Fhenix/Filler.yml b/styles/Fhenix/Filler.yml index 4e2f676e..0c94e173 100644 --- a/styles/Fhenix/Filler.yml +++ b/styles/Fhenix/Filler.yml @@ -1,6 +1,6 @@ extends: existence message: "Filler phrase: '%s'. Cut it or say the thing directly." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#words +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#words level: error ignorecase: true tokens: diff --git a/styles/Fhenix/FutureTense.yml b/styles/Fhenix/FutureTense.yml index ad38525a..7f6d569c 100644 --- a/styles/Fhenix/FutureTense.yml +++ b/styles/Fhenix/FutureTense.yml @@ -1,6 +1,6 @@ extends: existence message: "Present tense for how the system works: '%s'. Planned behavior belongs on the future plans page, labeled as planned." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#voice +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#voice level: suggestion ignorecase: true tokens: diff --git a/styles/Fhenix/Headings.yml b/styles/Fhenix/Headings.yml index d1e2fa45..bb7a010f 100644 --- a/styles/Fhenix/Headings.yml +++ b/styles/Fhenix/Headings.yml @@ -1,6 +1,6 @@ extends: capitalization message: "Headings use sentence case: '%s'." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#page-structure +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#page-structure level: warning scope: heading match: $sentence diff --git a/styles/Fhenix/Idioms.yml b/styles/Fhenix/Idioms.yml index 2d751b6a..a686cec2 100644 --- a/styles/Fhenix/Idioms.yml +++ b/styles/Fhenix/Idioms.yml @@ -1,6 +1,6 @@ extends: existence message: "Idiom: '%s'. Say what happens instead. Idioms cost non-native readers a lookup." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#words +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#words level: warning ignorecase: true tokens: diff --git a/styles/Fhenix/InternalNames.yml b/styles/Fhenix/InternalNames.yml index 9705ac73..f7d3c238 100644 --- a/styles/Fhenix/InternalNames.yml +++ b/styles/Fhenix/InternalNames.yml @@ -1,6 +1,6 @@ extends: existence message: "Possible internal name: '%s'. Internal hosts, projects, environments, and flags do not belong in public docs." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#terminology +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#terminology level: warning ignorecase: true tokens: diff --git a/styles/Fhenix/LinkText.yml b/styles/Fhenix/LinkText.yml index f9cbad8d..caf4805d 100644 --- a/styles/Fhenix/LinkText.yml +++ b/styles/Fhenix/LinkText.yml @@ -1,6 +1,6 @@ extends: existence message: "Vague link text: '%s'. Describe the destination." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#links-images-and-components +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#links-images-and-components level: warning scope: raw ignorecase: true diff --git a/styles/Fhenix/Marketing.yml b/styles/Fhenix/Marketing.yml index c10a2364..167c922d 100644 --- a/styles/Fhenix/Marketing.yml +++ b/styles/Fhenix/Marketing.yml @@ -1,6 +1,6 @@ extends: existence message: "Marketing adjective: '%s'. Describe the actual behavior instead." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#words +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#words level: error ignorecase: true tokens: diff --git a/styles/Fhenix/SentenceLength.yml b/styles/Fhenix/SentenceLength.yml index a4cf1968..caf891c0 100644 --- a/styles/Fhenix/SentenceLength.yml +++ b/styles/Fhenix/SentenceLength.yml @@ -1,6 +1,6 @@ extends: occurrence message: "Sentence is over 30 words. Aim for under 25. Split it." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#sentences-and-paragraphs +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#sentences-and-paragraphs level: warning scope: sentence ignorecase: false diff --git a/styles/Fhenix/SmartQuotes.yml b/styles/Fhenix/SmartQuotes.yml index 1fa00a49..d20637b3 100644 --- a/styles/Fhenix/SmartQuotes.yml +++ b/styles/Fhenix/SmartQuotes.yml @@ -1,6 +1,6 @@ extends: existence message: "Use straight quotes and apostrophes, not '%s'." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#punctuation-and-symbols +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/STYLE.md#punctuation-and-symbols level: warning nonword: true tokens: diff --git a/styles/Fhenix/Terms.yml b/styles/Fhenix/Terms.yml index 9b1b3537..3abd9c38 100644 --- a/styles/Fhenix/Terms.yml +++ b/styles/Fhenix/Terms.yml @@ -1,6 +1,6 @@ extends: substitution message: "Use '%s', not '%s'." -link: https://github.com/FhenixProtocol/fhenix-developer-docs/blob/main/STYLE.md#terminology +link: https://github.com/FhenixProtocol/fhenix-docs/blob/main/cofhe/STYLE-cofhe.md#terminology level: error ignorecase: false swap: diff --git a/wallet/AGENTS.md b/wallet/AGENTS.md new file mode 100644 index 00000000..79e9feef --- /dev/null +++ b/wallet/AGENTS.md @@ -0,0 +1,14 @@ +# Wallet Module docs + +Pages under `wallet/` document the Fhenix Wallet Module, served at `/wallet/...`. The root `AGENTS.md` and `STYLE.md` apply here too. + +The content and layout are not decided yet. Today the product has one "Coming soon" page. + +Yonatan and Alex review wallet changes. + +## Facts + +- Never write a technical claim you have not verified against the current source of the relevant repo or the published packages. Docs drift is the failure mode this project exists to fix. +- Current behavior and future plans never mix. Label future work as such, on its own page. +- No internal names: hostnames, cloud project names, environment names, deployment bundle names, feature flags. +- Never link to a private repository; readers get a 404. diff --git a/wallet/CLAUDE.md b/wallet/CLAUDE.md new file mode 100644 index 00000000..79e9feef --- /dev/null +++ b/wallet/CLAUDE.md @@ -0,0 +1,14 @@ +# Wallet Module docs + +Pages under `wallet/` document the Fhenix Wallet Module, served at `/wallet/...`. The root `AGENTS.md` and `STYLE.md` apply here too. + +The content and layout are not decided yet. Today the product has one "Coming soon" page. + +Yonatan and Alex review wallet changes. + +## Facts + +- Never write a technical claim you have not verified against the current source of the relevant repo or the published packages. Docs drift is the failure mode this project exists to fix. +- Current behavior and future plans never mix. Label future work as such, on its own page. +- No internal names: hostnames, cloud project names, environment names, deployment bundle names, feature flags. +- Never link to a private repository; readers get a 404. From f63755d1a7c66d2b528a2a029cba6f66a9dac277 Mon Sep 17 00:00:00 2001 From: haim Date: Tue, 13 Oct 2026 16:35:13 +0300 Subject: [PATCH 4/5] [CHORE] Scope CoFHE CI and scripts to cofhe/ --- .github/workflows/docs-versions.yml | 12 ++++++------ .github/workflows/mint-check.yml | 1 + .github/workflows/sample-compile.yml | 12 ++++++------ .github/workflows/update-cofhe-errors-docs.yml | 2 +- STYLE.md | 4 ++-- {scripts => cofhe/scripts}/check-versions.py | 8 ++++---- {scripts => cofhe/scripts}/compile-samples.py | 4 ++-- scripts/lint-docs.py | 9 +++++++-- 8 files changed, 29 insertions(+), 23 deletions(-) rename {scripts => cofhe/scripts}/check-versions.py (95%) rename {scripts => cofhe/scripts}/compile-samples.py (98%) diff --git a/.github/workflows/docs-versions.yml b/.github/workflows/docs-versions.yml index 43d87ffe..96f0e639 100644 --- a/.github/workflows/docs-versions.yml +++ b/.github/workflows/docs-versions.yml @@ -3,8 +3,8 @@ name: Docs versions on: pull_request: paths: - - '**/*.mdx' - - 'scripts/check-versions.py' + - 'cofhe/**/*.mdx' + - 'cofhe/scripts/check-versions.py' - '.github/workflows/sample-compile.yml' # Weekly, so a release upstream surfaces as an issue rather than waiting for # someone to notice a stale install command. @@ -30,7 +30,7 @@ jobs: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - - run: python3 scripts/check-versions.py --docs + - run: python3 cofhe/scripts/check-versions.py --docs # This one does hit the network, and a new release upstream is not a reason to # fail an unrelated pull request, so it never runs on one. @@ -47,7 +47,7 @@ jobs: - name: Check npm id: check run: | - if python3 scripts/check-versions.py --npm > drift.txt 2>&1; then + if python3 cofhe/scripts/check-versions.py --npm > drift.txt 2>&1; then echo "drifted=false" >> "$GITHUB_OUTPUT" else echo "drifted=true" >> "$GITHUB_OUTPUT" @@ -69,8 +69,8 @@ jobs: fs.readFileSync('drift.txt', 'utf8').trim(), '```', '', - 'Update `get-started/introduction/compatibility.mdx`, then run', - '`python3 scripts/check-versions.py --docs` to find every pin that', + 'Update `cofhe/get-started/introduction/compatibility.mdx`, then run', + '`python3 cofhe/scripts/check-versions.py --docs` to find every pin that', 'needs to move with it, including the package pins in', '`.github/workflows/sample-compile.yml`.', ].join('\n'); diff --git a/.github/workflows/mint-check.yml b/.github/workflows/mint-check.yml index cf244d1a..fb75dac6 100644 --- a/.github/workflows/mint-check.yml +++ b/.github/workflows/mint-check.yml @@ -6,6 +6,7 @@ on: - '**/*.mdx' - '**/*.md' - 'docs.json' + - '.mintignore' workflow_dispatch: # A force-push supersedes the previous run; the site-wide checks take long diff --git a/.github/workflows/sample-compile.yml b/.github/workflows/sample-compile.yml index 62b27834..417fd99f 100644 --- a/.github/workflows/sample-compile.yml +++ b/.github/workflows/sample-compile.yml @@ -3,14 +3,14 @@ name: Sample compile on: pull_request: paths: - - '**/*.mdx' - - 'scripts/compile-samples.py' + - 'cofhe/**/*.mdx' + - 'cofhe/scripts/compile-samples.py' - '.github/workflows/sample-compile.yml' workflow_dispatch: env: # The Solidity dependency versions the docs tell readers to install; see - # get-started/introduction/compatibility.mdx. scripts/check-versions.py + # cofhe/get-started/introduction/compatibility.mdx. cofhe/scripts/check-versions.py # --docs fails when these disagree with that page. COFHE_CONTRACTS_VERSION: 1.0.0 CONFIDENTIAL_CONTRACTS_VERSION: 0.4.0 @@ -35,9 +35,9 @@ jobs: run: | if [ "${{ github.event_name }}" = "pull_request" ]; then git diff --name-only --diff-filter=d \ - "origin/${{ github.base_ref }}...HEAD" -- '*.mdx' > files.txt + "origin/${{ github.base_ref }}...HEAD" -- 'cofhe/*.mdx' 'cofhe/**/*.mdx' > files.txt else - git ls-files '*.mdx' > files.txt + git ls-files 'cofhe/*.mdx' 'cofhe/**/*.mdx' > files.txt fi count=$(wc -l < files.txt | tr -d ' ') echo "count=$count" >> "$GITHUB_OUTPUT" @@ -74,4 +74,4 @@ jobs: # checked; this check is Solidity only. - name: Compile Solidity samples if: steps.files.outputs.count != '0' - run: xargs -a files.txt python3 scripts/compile-samples.py + run: xargs -a files.txt python3 cofhe/scripts/compile-samples.py diff --git a/.github/workflows/update-cofhe-errors-docs.yml b/.github/workflows/update-cofhe-errors-docs.yml index 50354f7d..7ed740d3 100644 --- a/.github/workflows/update-cofhe-errors-docs.yml +++ b/.github/workflows/update-cofhe-errors-docs.yml @@ -53,7 +53,7 @@ jobs: }, { role: 'user', - content: `Update the CoFHE errors documentation page with these error definitions from @fhenixprotocol/cofhe-errors v${version}:\n\n\`\`\`json\n${errorsJson}\n\`\`\`\n\nCreate/update a reference page with a table: Error Name, Selector, Signature, Source Contract, Parameters. Group by source contract.` + content: `Update the CoFHE errors documentation page with these error definitions from @fhenixprotocol/cofhe-errors v${version}:\n\n\`\`\`json\n${errorsJson}\n\`\`\`\n\nCreate/update a reference page with a table: Error Name, Selector, Signature, Source Contract, Parameters. Group by source contract. The page is cofhe/fhe-library/reference/cofhe-errors-reference.mdx; never create pages outside cofhe/.` } ], asDraft: false diff --git a/STYLE.md b/STYLE.md index 722090bb..b254770c 100644 --- a/STYLE.md +++ b/STYLE.md @@ -132,7 +132,7 @@ Most of this guide is mechanical, so linters enforce it instead of a reviewer. - Prose: [Vale](https://vale.sh), with our rules in `styles/Fhenix/` and configuration in `.vale.ini`. It catches em dashes, decorative Unicode, filler phrases, marketing adjectives, "simple" and "easy", idioms, vague link text, non-canonical terminology, Title Case headings, and overlong sentences. - Structure: `scripts/lint-docs.py`, which reads what Vale cannot see. It catches missing frontmatter, manual H1 headings, skipped heading levels, code blocks with no language tag, relative or absolute internal links, and images with no alt text. -- Versions: `scripts/check-versions.py`, which treats the [compatibility page](get-started/introduction/compatibility.mdx) as the single source of truth and fails when any pin elsewhere disagrees with it. Update that page first, then run the script to find every install command and table that has to move with it. +- Versions (CoFHE): `cofhe/scripts/check-versions.py`, which treats the [compatibility page](cofhe/get-started/introduction/compatibility.mdx) as the single source of truth and fails when any pin elsewhere disagrees with it. Update that page first, then run the script to find every install command and table that has to move with it. Run both on what you changed, before you open a pull request: @@ -141,7 +141,7 @@ brew install vale FILES=$(git diff --name-only --diff-filter=d origin/main...HEAD -- '*.mdx') python3 scripts/lint-docs.py $FILES vale $FILES -python3 scripts/check-versions.py --docs +python3 cofhe/scripts/check-versions.py --docs ``` A version that is deliberately old, because the sentence is describing history, opts out with a `` comment on the same line. A version written as `package@v1.2.3` is read as a historical reference and never checked. diff --git a/scripts/check-versions.py b/cofhe/scripts/check-versions.py similarity index 95% rename from scripts/check-versions.py rename to cofhe/scripts/check-versions.py index ba9f15c1..6d77d49f 100755 --- a/scripts/check-versions.py +++ b/cofhe/scripts/check-versions.py @@ -13,8 +13,8 @@ which is not a reason to fail an unrelated pull request, so it runs on a schedule. Usage: - python3 scripts/check-versions.py --docs [files...] # defaults to every .mdx - python3 scripts/check-versions.py --npm + python3 cofhe/scripts/check-versions.py --docs [files...] # defaults to every cofhe/ .mdx + python3 cofhe/scripts/check-versions.py --npm Exits 1 if any mismatch is found. See STYLE.md. """ @@ -25,7 +25,7 @@ import sys from pathlib import Path -TRUTH = Path("get-started/introduction/compatibility.mdx") +TRUTH = Path("cofhe/get-started/introduction/compatibility.mdx") # Historical references name a version to say when something changed, which is a # fact about the past rather than a pin that can go stale. They are written with a @@ -128,7 +128,7 @@ def main(argv): failed = False if mode_docs: - paths = [Path(a) for a in args] or sorted(Path(".").rglob("*.mdx")) + paths = [Path(a) for a in args] or sorted(Path("cofhe").rglob("*.mdx")) paths = [p for p in paths if p.suffix == ".mdx" and p.exists()] problems = scan(paths, versions) + scan_workflow(versions) for path, n, message in problems: diff --git a/scripts/compile-samples.py b/cofhe/scripts/compile-samples.py similarity index 98% rename from scripts/compile-samples.py rename to cofhe/scripts/compile-samples.py index 6c0fd65e..588d016b 100644 --- a/scripts/compile-samples.py +++ b/cofhe/scripts/compile-samples.py @@ -1,7 +1,7 @@ #!/usr/bin/env python3 """Compile the Solidity code samples of the given .mdx pages. -Usage: python3 scripts/compile-samples.py [ ...] +Usage: python3 cofhe/scripts/compile-samples.py [ ...] The script extracts every ```solidity fenced block, turns each block into a .sol file inside a throwaway Foundry project, and runs one `forge build`. @@ -52,7 +52,7 @@ import tempfile from pathlib import Path -# Keep in step with FHE.sol's own pragma (see get-started/introduction/compatibility.mdx). +# Keep in step with FHE.sol's own pragma (see cofhe/get-started/introduction/compatibility.mdx). SOLC_VERSION = "0.8.28" SCAFFOLD_PRAGMA = "pragma solidity >=0.8.25 <0.9.0;" FHE_IMPORT = 'import "@fhenixprotocol/cofhe-contracts/FHE.sol";' diff --git a/scripts/lint-docs.py b/scripts/lint-docs.py index f2588bad..c6f72ffe 100755 --- a/scripts/lint-docs.py +++ b/scripts/lint-docs.py @@ -16,6 +16,7 @@ from pathlib import Path GUIDE = "STYLE.md" +OLD_COFHE_LINK = re.compile(r'(\]\(|href="|src=")(/(?:get-started|client-sdk|fhe-library|tutorials|deep-dive|images)(?=[/)"#])[^)"\s]*)') def parse(path: Path): @@ -80,9 +81,13 @@ def err(line_no, rule, message): continue for match in re.finditer(r'\]\((\.\.?/[^)\s]*)\)', line): - err(n, "link-path", f"Relative link `{match.group(1)}`. Use a root-relative path, such as `/fhe-library/core-concepts/access-control`.") - for match in re.finditer(r'\]\((https?://(?:cofhe-)?docs\.fhenix\.zone[^)\s]*)\)', line): + err(n, "link-path", f"Relative link `{match.group(1)}`. Use a root-relative path, such as `/cofhe/fhe-library/core-concepts/access-control`.") + for match in re.finditer(r'\]\((https?://(?:(?:cofhe-)?docs\.fhenix\.zone|docs\.fhenix\.io)[^)\s]*)\)', line): err(n, "link-path", f"Absolute link to our own site `{match.group(1)}`. Use a root-relative path so preview deployments resolve.") + # Pre-move CoFHE paths still resolve through wildcard redirects, so + # mint broken-links accepts them and they would pile up unnoticed. + for match in OLD_COFHE_LINK.finditer(line): + err(n, "link-path", f"Old CoFHE path `{match.group(2)}`. CoFHE pages live under `/cofhe`: use `/cofhe{match.group(2)}`.") if re.search(r'!\[\s*\]\(', line): err(n, "alt-text", "Image has no alt text. Describe what the image shows.") for match in re.finditer(r']*>', line): From f24cd18a2b6cca37c974cec50f9fd4ba320c6a9b Mon Sep 17 00:00:00 2001 From: haim Date: Tue, 13 Oct 2026 16:49:29 +0300 Subject: [PATCH 5/5] [DOCS] Replace em dashes flagged by the style check --- cofhe/client-sdk/guides/error-handling.mdx | 12 ++++++------ cofhe/fhe-library/core-concepts/randomness.mdx | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/cofhe/client-sdk/guides/error-handling.mdx b/cofhe/client-sdk/guides/error-handling.mdx index 1e5b505d..2b3ffbce 100644 --- a/cofhe/client-sdk/guides/error-handling.mdx +++ b/cofhe/client-sdk/guides/error-handling.mdx @@ -26,15 +26,15 @@ try { Two fields are always set: -- `code: CofheErrorCode` — the enum value identifying the error type -- `message: string` — a human-readable description of what went wrong +- `code: CofheErrorCode`: the enum value identifying the error type +- `message: string`: a human-readable description of what went wrong Four more are declared optional on the class. The property always exists; its value is `undefined` unless the code that threw supplied it, so narrow before using it: -- `hint?: string` — an actionable suggestion for fixing the error. Set by most SDK throw sites, but not all -- `context?: Record` — the state that produced the error. For a `ZkPackFailed` from oversized inputs this holds `totalBits`, `maxBits`, and the offending `items` -- `cause?: Error` — the inner error being wrapped. When set, its message is also appended to `message` as `| Caused by: ...` -- `apiErrorCode?: string` — the raw backend error string. Set only on errors built from a decryption backend response +- `hint?: string`: an actionable suggestion for fixing the error. Set by most SDK throw sites, but not all +- `context?: Record`: the state that produced the error. For a `ZkPackFailed` from oversized inputs this holds `totalBits`, `maxBits`, and the offending `items` +- `cause?: Error`: the inner error being wrapped. When set, its message is also appended to `message` as `| Caused by: ...` +- `apiErrorCode?: string`: the raw backend error string. Set only on errors built from a decryption backend response Because the four are optional, guard each one rather than assuming it is there: diff --git a/cofhe/fhe-library/core-concepts/randomness.mdx b/cofhe/fhe-library/core-concepts/randomness.mdx index ed811061..80e56ada 100644 --- a/cofhe/fhe-library/core-concepts/randomness.mdx +++ b/cofhe/fhe-library/core-concepts/randomness.mdx @@ -5,7 +5,7 @@ description: "Generating encrypted random values in confidential smart contracts ## Overview -The FHE library provides cryptographically secure random number generation that produces encrypted random values. The values are generated in encrypted form—no one can see the plaintext until it is explicitly decrypted. +The FHE library provides cryptographically secure random number generation that produces encrypted random values. The values are generated in encrypted form, so no one can see the plaintext until it is explicitly decrypted. ## Random Functions