From 01e8fe1f2302066ba1b90e7abc0cfde47ad0b9df Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 17 Sep 2026 20:37:23 +0000 Subject: [PATCH 1/2] docs(transparency): publish deployment disclosure and control model Add native/DEPLOYMENT-TRANSPARENCY.md defining what every public deployment should publish: a manifest of addresses, source commit, compiler identity and runtime bytecode hashes; the fixed control model; the operator powers that remain; permitted native-QRL fund paths; and a reviewer verification checklist. Surface the same control model in the app so users see it before depositing: - StakePage: "What the operator cannot change" card and an "No upgrade authority" hero badge - HowItWorksPage: "Immutable by construction" section - LegalPage: "Operator control and contract immutability" section Each placement states both halves honestly -- no owner, upgrader, proxy admin, pauser, fund rescue, balance setter or mutable fee role, while validator signing (performance, penalties, execution-tip routing) remains an operational trust assumption. Link the template from the README alongside the security review. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01RAKxypTyUJgDhHZbbcuS8C --- README.md | 2 + frontend/src/pages/HowItWorksPage.tsx | 23 ++++++++ frontend/src/pages/LegalPage.tsx | 25 ++++++++ frontend/src/pages/StakePage.tsx | 34 ++++++++++- native/DEPLOYMENT-TRANSPARENCY.md | 83 +++++++++++++++++++++++++++ 5 files changed, 166 insertions(+), 1 deletion(-) create mode 100644 native/DEPLOYMENT-TRANSPARENCY.md diff --git a/README.md b/README.md index cf6585a..988ce94 100644 --- a/README.md +++ b/README.md @@ -6,6 +6,8 @@ The native contracts, accounting model, proof tools and application checks are i The [final security review](native/FINAL-SECURITY-REVIEW.md) records the resolved findings, release-candidate checks and remaining launch gates. +The [deployment transparency template](native/DEPLOYMENT-TRANSPARENCY.md) defines the addresses, bytecode hashes, immutable roles and remaining operator powers that should be published for every public deployment. + ## Economic rules - Native validators use the unchanged 40,000 QRL protocol amount. The immutable validator operator first risks its own 2,000 QRL preparation deposit; contracts authenticate the canonical pool recipient before atomically adopting that principal and releasing the 38,000 QRL pooled top-up. diff --git a/frontend/src/pages/HowItWorksPage.tsx b/frontend/src/pages/HowItWorksPage.tsx index 5469775..3997543 100644 --- a/frontend/src/pages/HowItWorksPage.tsx +++ b/frontend/src/pages/HowItWorksPage.tsx @@ -26,6 +26,7 @@ const sections = [ "Each pool admits at most 64 validators over its lifetime. An immutable operator address authorizes new validator preparations. Signed validator exits are stored publicly before pooled top-up funding. An independent relayer can submit them when the unmodified protocol permits. Anyone holding a public signature can also force an eligible early exit, reducing validation uptime. Each replacement validator uses another lifetime admission. This public-exit policy remains subject to review before launch. Eligibility, inclusion and validator withdrawal timing still apply. If finality verification or complete pool accounting exceeds its immutable deadline, anyone can trigger recovery: pending deposit refunds and reserved claims remain payable, and frozen positions receive their share of available and later returned cash without new fees.", ], ] as const; + export function HowItWorksPage() { return (
@@ -46,6 +47,28 @@ export function HowItWorksPage() { ))} + + + Immutable by construction + + +

+ The native contract graph has no owner, upgrader, proxy admin, + pauser, arbitrary fund rescue, balance setter or mutable fee role. + Critical contract references and the fee recipient are fixed at + deployment. The operator cannot replace the pool implementation, + change the fee percentage or redirect validator withdrawals to a + different recipient. +

+

+ Validator operation is still an operator responsibility. Validator + signing can affect performance, losses and execution-tip routing, + but consensus withdrawals are bound to the pool contract. A future + QuantaPool version requires a separate deployment. Existing deployed + code does not become a new version automatically. +

+ + diff --git a/frontend/src/pages/LegalPage.tsx b/frontend/src/pages/LegalPage.tsx index e1ac8e6..c4e2091 100644 --- a/frontend/src/pages/LegalPage.tsx +++ b/frontend/src/pages/LegalPage.tsx @@ -27,6 +27,31 @@ export function LegalPage() {

+ + + + Operator control and contract immutability + + + +

+ The active native contract graph has no owner, upgrader, proxy + admin, pauser, arbitrary fund rescue, balance setter or mutable fee + role. Critical contract references and the fee recipient are fixed + at deployment. The operator cannot replace deployed pool logic, + change the fee percentage or redirect validator withdrawals to a + different recipient. +

+

+ The validator operator still controls validator signing and can + affect validator performance, penalties and execution-tip routing. + Those operational powers do not provide an administrative path to + withdraw user principal from the pool. A future protocol version + requires a separate deployment rather than changing an existing + pool in place. +

+ + Risks and limitations diff --git a/frontend/src/pages/StakePage.tsx b/frontend/src/pages/StakePage.tsx index 4e9b011..cab173c 100644 --- a/frontend/src/pages/StakePage.tsx +++ b/frontend/src/pages/StakePage.tsx @@ -78,7 +78,7 @@ export const StakePage = observer(() => {

Non-transferable positions · No - guaranteed return + upgrade authority · No guaranteed return

@@ -211,6 +211,38 @@ export const StakePage = observer(() => {
+
+ + + + What the operator cannot change + + + The native pool is designed so deployment fixes the rules that + control user funds. + + + +

+ There is no owner, upgrader, proxy admin, pauser, arbitrary fund + rescue, balance setter or mutable fee role. The operator cannot + replace the deployed pool logic, change the 10% fee or redirect + validator withdrawals away from the pool. +

+

+ The operator still runs validator signing infrastructure, so + validator performance, penalties and execution-tip routing remain + operational trust assumptions.{" "} + + See the full control and recovery model. + +

+ + +
diff --git a/native/DEPLOYMENT-TRANSPARENCY.md b/native/DEPLOYMENT-TRANSPARENCY.md new file mode 100644 index 0000000..0040d69 --- /dev/null +++ b/native/DEPLOYMENT-TRANSPARENCY.md @@ -0,0 +1,83 @@ +# Deployment transparency + +This document defines the information QuantaPool should publish for every public native-QRL contract graph. It is a technical disclosure template, not a legal classification. + +The goal is simple: a user, reviewer or regulator should be able to verify which code is deployed, which powers exist, which powers do not exist and which operator responsibilities remain. + +## Deployment manifest + +Complete this table for each public deployment before accepting public funds. + +| Field | Published value | +| --- | --- | +| Network | `` | +| Pool | `
` | +| Validator gate | `
` | +| Portfolio verifier | `
` | +| Finality verifier | `
` | +| Canonical deposit contract | `
` | +| Validator operator | `
` | +| Fee recipient | `
` | +| Source commit | `` | +| Compiler identity | `` | +| Pool runtime SHA-256 | `` | +| Validator gate runtime SHA-256 | `` | +| Deployment transaction or block | `` | +| Initial trusted checkpoint | `` | + +The deployment manifest should be published in the repository and linked from the web application. + +## Fixed control model + +For the current native design, deployment is intended to establish all of the following properties: + +- no owner role +- no upgrade role +- no proxy admin +- no pauser +- no arbitrary fund rescue +- no balance setter +- no mutable fee role +- fixed 10% fee logic for eligible realized net consensus gains +- immutable fee recipient +- immutable pool, gate, portfolio and finality bindings +- validator consensus withdrawals bound to the pool +- canonical deposit runtime pinned by address and code hash +- no transferable staking receipt token + +A future QuantaPool version should use a separate deployment. Existing deployed pool code should not change in place. + +## What the operator can still do + +Immutability does not remove every trust assumption. The validator operator still controls validator signing infrastructure and therefore can affect validator availability, penalties and execution-tip routing. The operator also prepares new validator keys using its own bootstrap capital. + +Those operational powers should be disclosed separately from contract administration. They do not create an owner or upgrade path in the current native contract graph. + +## User fund paths + +The public disclosure should state the permitted native-QRL paths in plain language: + +1. users deposit QRL into the pool contract +2. pooled validator funding is released only through the bound validator gate +3. validator withdrawal credentials point back to the pool +4. user claims pay the recorded position beneficiary +5. the fee recipient can receive only earned fee reserves +6. permanent recovery pays available and later returned cash according to frozen positions + +Any production deployment should be checked against these statements before the frontend is configured to use it. + +## Verification checklist + +For each deployment, reviewers should verify the following against deployed bytecode and the published source commit: + +- runtime bytecode matches the published build artifact +- no proxy or implementation slot is used to replace pool logic +- no callable owner, admin, upgrade, pause, rescue or balance-setting path exists +- immutable constructor bindings match the published addresses +- fee logic and fee recipient match the manifest +- validator deposits encode the pool as withdrawal recipient +- the canonical deposit contract address and runtime hash match the qualified network value +- the frontend is configured for the same pool address and network +- the source, compiler and artifact fingerprints are reproducible from the published build inputs + +The repository security review and implementation report provide the current pre-launch evidence. A deployment-specific manifest should reference those documents and add the final on-chain addresses and bytecode hashes. From 8748c2fcc1df05e6b80101ea82719f5ee6de9c8a Mon Sep 17 00:00:00 2001 From: moscowchill Date: Fri, 18 Sep 2026 10:55:18 +0200 Subject: [PATCH 2/2] docs: drop contrastive phrasing from transparency copy --- frontend/src/pages/LegalPage.tsx | 4 ++-- native/DEPLOYMENT-TRANSPARENCY.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/frontend/src/pages/LegalPage.tsx b/frontend/src/pages/LegalPage.tsx index c4e2091..2c685ab 100644 --- a/frontend/src/pages/LegalPage.tsx +++ b/frontend/src/pages/LegalPage.tsx @@ -47,8 +47,8 @@ export function LegalPage() { affect validator performance, penalties and execution-tip routing. Those operational powers do not provide an administrative path to withdraw user principal from the pool. A future protocol version - requires a separate deployment rather than changing an existing - pool in place. + requires a separate deployment. Existing pool code stays fixed in + place.

diff --git a/native/DEPLOYMENT-TRANSPARENCY.md b/native/DEPLOYMENT-TRANSPARENCY.md index 0040d69..8d8f0ba 100644 --- a/native/DEPLOYMENT-TRANSPARENCY.md +++ b/native/DEPLOYMENT-TRANSPARENCY.md @@ -1,6 +1,6 @@ # Deployment transparency -This document defines the information QuantaPool should publish for every public native-QRL contract graph. It is a technical disclosure template, not a legal classification. +This document defines the information QuantaPool should publish for every public native-QRL contract graph. It is a technical disclosure template and carries no legal classification. The goal is simple: a user, reviewer or regulator should be able to verify which code is deployed, which powers exist, which powers do not exist and which operator responsibilities remain.