docs(transparency): publish deployment disclosure and control model

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.

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 (
     <div className="page-enter mx-auto max-w-3xl space-y-4 py-6">
@@ -46,6 +47,28 @@ export function HowItWorksPage() {
           </CardContent>
         </Card>
       ))}
+      <Card className="border-l-2 border-l-identity-accent">
+        <CardHeader>
+          <CardTitle className="text-lg">Immutable by construction</CardTitle>
+        </CardHeader>
+        <CardContent className="space-y-3 text-sm leading-relaxed text-muted-foreground">
+          <p>
+            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.
+          </p>
+          <p>
+            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.
+          </p>
+        </CardContent>
+      </Card>
       <Card className="border-l-2 border-l-secondary">
         <CardHeader>
           <CardTitle className="text-lg">

frontend/src/pages/LegalPage.tsx

@@ -27,6 +27,31 @@ export function LegalPage() {
           </p>
         </CardContent>
       </Card>
+      <Card className="border-l-2 border-l-identity-accent">
+        <CardHeader>
+          <CardTitle className="text-lg">
+            Operator control and contract immutability
+          </CardTitle>
+        </CardHeader>
+        <CardContent className="space-y-3 text-sm leading-relaxed text-muted-foreground">
+          <p>
+            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.
+          </p>
+          <p>
+            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. Existing pool code stays fixed in
+            place.
+          </p>
+        </CardContent>
+      </Card>
       <Card>
         <CardHeader>
           <CardTitle className="text-lg">Risks and limitations</CardTitle>

frontend/src/pages/StakePage.tsx

@@ -78,7 +78,7 @@ export const StakePage = observer(() => {
         </p>
         <p className="mt-3 inline-flex items-center gap-2 text-xs text-identity-accent">
           <ShieldCheck className="h-4 w-4" /> Non-transferable positions · No
-          guaranteed return
+          upgrade authority · No guaranteed return
         </p>
       </section>
       <section className="mx-auto grid max-w-3xl gap-4 md:grid-cols-2">
@@ -211,6 +211,38 @@ export const StakePage = observer(() => {
           </CardContent>
         </Card>
       </section>
+      <section className="mx-auto max-w-3xl">
+        <Card className="border-l-2 border-l-identity-accent">
+          <CardHeader>
+            <CardTitle className="text-lg">
+              What the operator cannot change
+            </CardTitle>
+            <CardDescription>
+              The native pool is designed so deployment fixes the rules that
+              control user funds.
+            </CardDescription>
+          </CardHeader>
+          <CardContent className="space-y-3 text-sm leading-relaxed text-muted-foreground">
+            <p>
+              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.
+            </p>
+            <p>
+              The operator still runs validator signing infrastructure, so
+              validator performance, penalties and execution-tip routing remain
+              operational trust assumptions.{" "}
+              <Link
+                to="/how-it-works"
+                className="text-identity-accent hover:underline"
+              >
+                See the full control and recovery model.
+              </Link>
+            </p>
+          </CardContent>
+        </Card>
+      </section>
       <section className="mx-auto max-w-3xl">
         <StatsBar />
       </section>

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 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.
+
+## Deployment manifest
+
+Complete this table for each public deployment before accepting public funds.
+
+| Field | Published value |
+| --- | --- |
+| Network | `<network>` |
+| Pool | `<address>` |
+| Validator gate | `<address>` |
+| Portfolio verifier | `<address>` |
+| Finality verifier | `<address>` |
+| Canonical deposit contract | `<address>` |
+| Validator operator | `<address>` |
+| Fee recipient | `<address>` |
+| Source commit | `<git commit>` |
+| Compiler identity | `<compiler version and source revision>` |
+| Pool runtime SHA-256 | `<sha256>` |
+| Validator gate runtime SHA-256 | `<sha256>` |
+| Deployment transaction or block | `<reference>` |
+| Initial trusted checkpoint | `<slot/root/reference>` |
+
+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.