ERC Discussion: Standardized Onchain Access Control for ERC-3668 / CCIP Read

ERCs
1

Hello all,

I would like to get feedback on a possible ERC proposal that extends the ERC-3668 / CCIP Read ecosystem with a standardized access control interface for offchain data access.

Background

ERC-3668 enables trust-minimized retrieval of offchain data via CCIP Read. It works well when the concern is authenticity and verifiability of data returned by a gateway.

However, ERC-3668 does not define a standard way to restrict who may access certain data or trigger certain offchain lookups.

This becomes a practical issue for:

  • enterprise or private datasets,
  • paid subscription data,
  • permissioned services,
  • metered or pay-per-use APIs.

Today, gateway operators typically solve this with custom API authentication or proprietary allowlists. But this creates a few problems:

  1. the access policy is usually enforced offchain,
  2. it is hard for the gateway operator to publicly prove who is authorized,
  3. authorization grants and revocations are not transparently recorded onchain,
  4. clients, gateways, and callback contracts may not evaluate authorization against the same state.

Problem Statement

For CCIP Read, we may want the gateway operator to publicly commit an authorization model onchain, so that:

  • authorization and revocation are recorded by onchain transactions,
  • access decisions are evaluated against a specific block number,
  • the client, gateway, and callback contract can all arrive at the same decision,
  • access control becomes composable and auditable rather than proprietary.

In other words, the goal is not to replace ERC-3668, but to define a standard access-control layer that can be used alongside it.

Core Idea

The rough idea is to standardize a minimal interface for access verification, while allowing multiple authorization models behind that interface.

Examples of possible access-control models include:

  1. Standalone principal registry
    A dedicated contract, or an inherited module, that maintains principals and authorization status.

  2. EAS-based attestation
    Access is granted if the requester holds a valid attestation satisfying some policy.

  3. Pay-per-use / x402-like model
    Access is granted after payment, or after presenting proof of payment / usage rights.

Because these models are quite different, I think the standard should avoid prescribing a single authorization mechanism. Instead, it may be better to define:

  • a common verification interface,
  • a way to bind one or more access-control modules to a CCIP Read flow,
  • a block-consistent evaluation model,
  • optional metadata so clients can discover which authorization scheme is in use.

This would make it possible to support:

  • multiple authorization schemes for a single CCIP contract
  • one shared authorization scheme across multiple CCIP contracts.

Desired Properties

Some properties I think such a standard should aim for:

  • Onchain authorization source of truth
    Grants and revocations should be represented onchain.

  • Block-consistent evaluation
    Access should be evaluated against a specific block number so that gateway, contract, and client can reason over the same state.

  • Composable design
    Different access models should be usable through a common interface.

  • Minimal assumptions about identity
    The principal may be an EOA, a smart account, or potentially another authenticated actor.

  • Compatibility with ERC-3668
    This should be an extension layer, not a replacement.

Open Design Questions

I would especially appreciate feedback on the following questions:

  1. Should this be a standalone ERC, or an extension specifically framed around ERC-3668?

  2. What should the principal model be?
    Should authorization be defined only for msg.sender-like actors, or should it support arbitrary subjects / delegates?

  3. What should the verification interface return?
    A simple boolean?
    A richer result including validity window, policy identifier, or proof requirements?

  4. How should block consistency be standardized?
    Should the gateway be required to evaluate against a specific block number included in the CCIP Read flow?

Tentative Scope

My current intuition is that the proposal should standardize only:

  • the interface for authorization checking,
  • the semantics for block-based verification,
  • how the access-control result composes with a CCIP Read flow,

while leaving the actual policy logic open.

Non-Goals

At least initially, I do not think this proposal should try to standardize:

  • a universal identity system,
  • a single canonical allowlist registry,
  • a specific payment rail,
  • a specific attestation framework,
  • transport-level API authentication details outside the CCIP Read flow.

Why this may be worth standardizing

Without a standard, every permissioned CCIP Read deployment will likely invent its own access-control mechanism, which reduces interoperability and makes client support harder.

A common interface could help wallets, clients, middleware, gateways, and contracts integrate permissioned offchain reads in a more predictable way.

I would appreciate feedback on whether this problem is real enough to justify standardization, and if so, what the narrowest useful standard would look like.

If there is enough interest, I can follow up with a more concrete draft ERC structure and interface sketch.

Thanks.

1 Like