docs: licenses and dev docs (#481)

# Description

- Prividium developer considerations
- ZK Stack & Prividium licenses

## Linked Issues

N/A

## Additional context

Author: uF4No

content/10.zk-stack/35.prividium/00.overview.md

@@ -7,6 +7,8 @@ while still **anchoring every transaction to Ethereum** for security and finalit
 
 Sensitive data stays entirely off the public chain, but each state update is verified on Ethereum using zero-knowledge proofs.
 
+:display_partial{path="/zk-stack/prividium/_partials/_license-callout"}
+
 This design solves a core challenge in enterprise blockchain adoption:
 **how to maintain privacy and control without giving up interoperability with the broader Ethereum ecosystem**.
 

content/10.zk-stack/35.prividium/06.deployment.md

@@ -6,6 +6,8 @@ description: Learn where to deploy each Prividium™ component.
 This page outlines the recommended deployment model for running a Prividium™ chain in production.
 Components are grouped by trust boundary and network tier, following enterprise best practices for security, scalability, and maintainability.
 
+:display_partial{path="/zk-stack/prividium/_partials/_license-callout"}
+
 ### DMZ / API Gateway Tier
 
 **Components:**
@@ -64,10 +66,3 @@ Unauthorized requests are filtered before reaching internal systems.
 - **Private consensus logic:** Sequencer and Prover run in a non-routable subnet. Only internal services can communicate with them.
 - **Outbound-only proof posting:** The relayer submits proofs to ZKsync Gateway without opening any inbound ports.
 - **Data-at-rest controls:** Databases and blob stores are isolated and regularly backed up to support compliance and disaster recovery.
-
-## Running a **Prividium™** Chain
-
-To run a local Prividium™ chain, go through the [Run Prividium™ Chain](/zk-stack/prividium/run-prividium-chain) page.
-
-For a full example application running on Prividium™,
-check out this [example escrow application](https://github.com/JackHamer09/interop-escrow-double-zero/tree/single-chain-demo).

content/10.zk-stack/35.prividium/10.run-prividium-chain.md

@@ -1,50 +1,53 @@
 ---
 title: Proxy RPC API
-description: Learn about the Prividium™ Proxy RPC API.
+description: Understand how the Prividium™ Proxy RPC enforces access control.
 ---
 
-In a standard rollup, there is a standard RPC API that provides full access
-to transaction data for users.
-With Prividium™, the Proxy RPC is an additional layer in between end users and the chain's standard RPC API.
+The Proxy RPC sits between end users and the chain's standard RPC API. It enforces transaction-level access control by filtering
+all blockchain interactions before they reach the sequencer.
 
-The purpose of the Proxy RPC API is to filter blockchain transactions and wallet interactions.
-It serves as an intermediary between web apps/wallets
-and blockchain data while enforcing transaction-level access control.
+:display_partial{path="/zk-stack/prividium/_partials/_license-callout"}
 
-Access to the standard RPC should remain private.
-We highly recommend implementing a secure firewall around the standard RPC API.
-Only the Proxy RPC API endpoint should be publicly shared.
+## How It Works
 
-## Setting up the Proxy
+The Proxy RPC validates every request against the [Permissions API](/zk-stack/prividium/permissions-overview):
 
-To set up the legacy Proxy, you can follow the instructions in the [local setup guide](/zk-stack/prividium/run-prividium-chain#proxy-rpc-api).
+1. User submits a transaction or query through the Proxy RPC
+2. Proxy validates the user's JWT and wallet address
+3. Proxy checks permissions for the requested contract function
+4. Authorized requests proceed to the standard RPC; unauthorized requests return `401 Unauthorized`
 
-The new implementation of the Proxy is not yet publicly available.
+::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
+Keep the standard RPC endpoint private. Implement a firewall to restrict access. Only expose the Proxy RPC publicly.
+::
 
 ## Limitations
 
-### Multicall contract methods
+### Multicall Contracts
 
-Currently, [multicall](https://docs.chainstack.com/docs/http-batch-request-vs-multicall-contract#multicall-contract) contract methods
-cannot be used in any access policy,
-as it would enable bypassing the other access policy rules.
+[Multicall](https://docs.chainstack.com/docs/http-batch-request-vs-multicall-contract#multicall-contract) contract methods
+bypass individual function permission checks. The Proxy blocks multicall patterns to prevent policy circumvention.
 
-### L1-L2 transactions
+### L1-L2 Transactions
 
-L1-L2 transactions, also known as forced transactions, originate from Ethereum (the L1) and can be force included on the L2 chain.
-In a public chain, this mechanism helps ensure censorship resistance for users,
-and allows them to retain full control of their assets.
+Forced transactions originating from Ethereum (L1) can bypass the Proxy entirely. These transactions provide censorship resistance
+on public chains but create security risks for permissioned networks:
 
-For Prividium™ chains though,
-forced transactions can also be a vector for deploying arbitrary contracts,
-performing arbitrary contract writes,
-and leaking data through blind attacks.
-The ZKsync protocol contracts have a way to
-[request arbitrary transaction](https://github.com/matter-labs/era-contracts/blob/29f9ff4bbe12dc133c852f81acd70e2b4139d6b2/l1-contracts/contracts/bridgehub/Bridgehub.sol#L216)
-to be executed from Ethereum,
-and it can be used to bypass the privacy configuration of a Prividium™ chain.
+- Deploy arbitrary contracts
+- Execute unauthorized writes
+- Leak data through blind attacks
 
-Currently **L1-L2 transactions are not automatically disabled** in Prividium™ chains.
-Prividium™ chain operators can be protected against malicious use of these forced transactions by implementing [transaction filtering](/zk-stack/customizations/transaction-filtering).
-Note that for users, this means that the chain has the ability to censor transactions.
-It is the responsibility of the chain operator to decide how to implement this filtering.
+**Mitigation:**
+
+L1-L2 transactions are **not automatically disabled**.
+Chain operators can implement [transaction filtering](/zk-stack/customizations/transaction-filtering) to control forced transaction behavior.
+
+The [`PrividiumTransactionFilterer`](https://github.com/matter-labs/era-contracts/blob/zksync-os-stable/l1-contracts/contracts/transactionFilterer/PrividiumTransactionFilterer.sol)
+contract provides an allowlist-based filter:
+
+- Allowlisted addresses execute unrestricted forced transactions
+- Other addresses can only transfer ETH or ERC-20 tokens
+
+::callout{icon="i-heroicons-light-bulb"}
+Enabling transaction filtering grants the chain operator censorship capability. Document your filtering policy for users.
+::

content/10.zk-stack/35.prividium/20.proxy.md

@@ -3,14 +3,11 @@ title: Permissions Overview
 description: Learn about the Prividium™ Permissioning API and Selective Disclosure.
 ---
 
-::callout{icon="i-heroicons-light-bulb"}
-The permissioning and selective disclosure systems are not yet publicly available.
-This documentation serves as a preview.
-::
-
 Prividium™ offers flexible and customizable ways for chain operators to have granular control over access to reading onchain data or calling contracts.
 There are two systems used to manage this control: the [permissions API](#permissions-api), and [selective disclosure](#selective-disclosure).
 
+:display_partial{path="/zk-stack/prividium/_partials/_license-callout"}
+
 ## Permissions API
 
 The permissions API is a layer in between the standard RPC API and the Proxy RPC API that controls **who** can call certain functions in a contract.

content/10.zk-stack/35.prividium/30.permissions-overview.md

@@ -3,6 +3,10 @@ title: Prividium™ SDK
 description: Get started with the Prividium™ SDK.
 ---
 
+::callout{icon="i-heroicons-light-bulb"}
+Unlike other Prividium™ components, the [Prividium™ SDK](/zk-stack/prividium/sdk) is distributed under the MIT License.
+::
+
 The [Prividium™ SDK](https://www.npmjs.com/package/prividium) is a TypeScript SDK for integrating with Prividium™'s authorization system.
 It provides a seamless authentication flow and secure RPC communication for applications running on a Prividium™, including:
 

content/10.zk-stack/35.prividium/40.sdk.md

@@ -2,6 +2,9 @@
 title: Private Block Explorer
 description: Learn about the Prividium™ Block Explorer.
 ---
+::callout{icon="i-heroicons-light-bulb"}
+The private block explorer is [under a commercial license](/zk-stack/prividium/license) and requires a license agreement or sandbox license to be used.
+::
 
 Like the RPC layer, the block explorer is split into to two versions with the Prividium™ framework:
 one public-facing and one internal.

content/10.zk-stack/35.prividium/50.explorer.md

@@ -0,0 +1,67 @@
+---
+title: Developer Considerations
+description: Key differences when building on Prividium™ chains.
+---
+
+Prividium™ chains enforce authentication and permissions at the RPC layer. Standard Web3 patterns require adaptation.
+
+## Authentication Required
+
+Every RPC interaction requires authentication. Unauthenticated requests fail.
+
+1. **Users authenticate** via OAuth 2.0 (OIDC providers or crypto-native SIWE).
+1. **Applications register** as OAuth clients in the Admin Panel.
+1. **Scripts authenticate** programmatically via the Permissions API.
+
+::callout{icon="i-heroicons-light-bulb"}
+Use the [Prividium™ SDK](/zk-stack/prividium/sdk) to manage authentication flows.
+::
+
+## Contract Deployment
+
+Deploying contracts requires explicit permissions granted by a chain administrator.
+
+1. **Request deployment permissions** from your network administrator.
+1. **Authenticate** before deployment using the CLI proxy, manual token injection, or Foundry headers.
+1. **Configure function permissions** in the Admin Panel immediately after deployment. All functions default to **Forbidden**.
+
+## Dual RPC Endpoints
+
+Prividium™ uses separate RPC endpoints depending on the use case.
+
+| Endpoint | Authentication | Used by |
+|----------|----------------|---------|
+| `/rpc` (Proxy RPC) | Bearer token in header | Browser wallets (MetaMask, etc.) |
+| `/wallet/{token}` (User RPC) | Token embedded in URL | Scripts (Viem, Ethers.js) |
+
+## Transaction Workflow
+
+Sending transactions via browser wallets (MetaMask, etc.) requires additional steps compared to public chains.
+
+1. **Pre-fetch parameters:** Retrieve nonce, gas estimate, and gas price using an authenticated client.
+1. **Enable wallet token:** Call `enableWalletToken()` from the Prividium™ SDK before each transaction.
+1. **Send transaction:** Include pre-fetched values explicitly.
+
+::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
+Wallet tokens are transaction-specific and expire. Enable them immediately before sending.
+::
+
+## Permission Model
+
+All contract interactions check permissions defined in the Admin Panel.
+
+- **Read functions:** Permissions checked on `eth_call`.
+- **Write functions:** Permissions checked on both simulation and execution.
+- **Default state:** All functions are **Forbidden** until configured.
+
+Configure access rules using permission types like **All Users**, **Check Role**, or **Restrict Argument**.
+
+## Key Differences from Public Chains
+
+| Aspect | Public Chain | Prividium™ |
+|--------|--------------|------------|
+| RPC Access | Open | Authenticated |
+| Contract Deployment | Permissionless | Requires permission |
+| Function Calls | Open | Permission-controlled |
+| Transaction Signing | Wallet only | Wallet + token enablement |
+| Network Configuration | Static RPC | User-specific RPC URLs |