> For the complete Linea documentation index, see [llms.txt](/llms.txt). > Agents can fetch this page as Markdown at [https://docs.linea.build/stack/deployment/access-control.md](https://docs.linea.build/stack/deployment/access-control.md). # Access control This page describes how a [Lineth](/protocol/reference/zero-knowledge-glossary#lineth)**Lineth** (Formerly the Linea Stack) The open-source ZK-rollup stack, codebase, and technical protocol that's the foundation of Linea Mainnet. Operators can deploy this stack to launch their own Ethereum-compatible L2 or L3 networks. [private validium](/protocol/reference/zero-knowledge-glossary#validium)**Validium** A deployment model in which a Lineth network proves state transitions with zk-SNARKs but keeps transaction data in a private data availability layer instead of publishing it to the finalization layer. Only state commitments and proofs are posted onchain, so participants without access to the offchain data can't independently reconstruct or verify the full transaction history. can restrict JSON-RPC access. In a restricted deployment, clients send all reads and writes to a single RPC endpoint. That endpoint authenticates callers and enforces role-based access control (RBAC) permissions. Access control is not cryptographic privacy Access control restricts who can use the operator's RPC. It does **not** restrict access to data that is already onchain, hide chain data from the operator who runs the node or stores the data, replace zero-knowledge proofs, or provide data availability. Operators typically configure access control on a private validium instead of a public deployment. Because a private validium keeps transaction data offchain, its access control endpoint is also the path to the chain data. ## Access control stack A restricted private validium exposes one RPC endpoint (the access control endpoint). Wallets, apps, and other clients access this endpoint, not the Lineth node directly. The access control endpoint: - Authenticates the caller. - Enforces rules for who can call which JSON-RPC methods and which contracts. - Forwards allowed requests to the node. - Returns only data the caller is permitted to see. Operators provision [roles and permissions](#role-based-access-control-rbac) (organizations, groups, users, and contract grants) through an admin API and UI. Permission data and JSON-RPC access logs are recorded in [audit databases](#audit-logs). Applications built on the stack must implement authentication and their own read and write flows on top of the endpoint. ### Role-based access control (RBAC) The endpoint enforces role-based access control (RBAC) inside an organization. Permissions belong to a group, not an individual user. - An **organization** is the tenant boundary. Users, groups, and contract registrations belong to an organization. - A **group** is a named collection of users that share one permission set. Groups can be marked as organization admin or read-only admin. - A **user** is an individual member of one or more groups, identified by a decentralized identifier (DID). Optional flags cover KYC status and bans. After the endpoint authenticates the caller, it checks the group's permission set. A permission set includes: - **Method allowlist:** Which JSON-RPC methods members may call. - **Claims:** Extra permissions on top of the method allowlist: - A `deploy` claim allows creating contracts. - An `upgrade` claim allows upgrading proxy (upgradeable) contracts. - An `admin` claim includes deploy and upgrade permissions. - **Contract grants:** Per-group permission on a registered contract: this group may use this contract, optionally limited to function selectors, parameter constraints, and event topics. Contracts stay private until a grant exists. - A missing function list means all functions on that contract are allowed. - An empty function list means all functions on that contract are denied. - An explicit list allows only those function selectors, optionally with parameter constraints (for example, a parameter that must equal the caller's own address). - Event rules can deny logs, allow all, or allow specific event topics. This RBAC data is stored in a dedicated database. The access control endpoint reads that data when it evaluates a request. ### Audit logs The access control endpoint writes two streams: - **Access log:** One record per JSON-RPC decision (allow or deny), stored in a database separate from RBAC data. Records are append-only: they cannot be edited or deleted. Each record is hashed with the previous one so a change is detectable. - **Control-plane audit:** One record each time an organization, group, user, membership, contract, or contract grant is created, updated, deleted, assigned, or revoked. These records live with the RBAC data. These logs are operator records of whether a request was allowed or denied under the active [RBAC](#role-based-access-control-rbac) permissions at that time. ## How a request is evaluated Clients send JSON-RPC requests to the access control endpoint, not to the Lineth node. The endpoint evaluates a typical request in this order: 1. Authenticate the caller via JSON Web Token (JWT). 2. Reject globally blocked methods (including `debug_*` and `admin_*` namespaces, and multicall patterns that would otherwise bypass contract grants). 3. Resolve the caller's organization, groups, and permissions. 4. Check the method against the group's RPC method allowlist. 5. If the call targets a contract, check that contract grant (and function selector, parameter, and event rules where they exist). 6. If the method is `eth_call` or `eth_estimateGas`, simulate the call with `debug_traceCall` and reject it if any internal `CALL`, `DELEGATECALL`, `STATICCALL`, `CREATE`, or `CREATE2` targets a contract the caller is not authorized to use (contract creation additionally requires the `deploy` claim). 7. Forward the request to the node, then redact the response before returning it. The endpoint binds the call's sender to the authenticated account, so a caller cannot inherit another account's onchain permissions by spoofing `from`. Evaluation is fail-closed: a missing permission, an unknown contract, a tracing failure, or an unreachable node during simulation denies the request. Denied JSON-RPC calls are returned to the client as a generic "method not found" error. The detailed reason is written to the access log for operators. Anonymous, unauthenticated requests can be limited to claim-free metadata such as `eth_chainId` and `eth_blockNumber`. They do not receive a view of private contracts or transaction data. ## See also - [Lineth-to-Lineth interoperability](/stack/deployment/interoperability): How two Lineth networks communicate with each other, and how an access controlled destination authorizes calls. - [Privacy and data visibility](/stack/evaluate/validium): How private validium deployments use offchain data availability and controlled access.