Part of RFC-27 (rfcs/rfc27-ip-verification.md); tracker #4194.
Context
#4197 added onchain IpOwnershipProof validation to CreateUser / CreateSubscribeUser, gated on the require-ip-ownership-proof feature flag. With the flag set, a valid proof is required for every user creation — except when the transaction payer is globalstate.sentinel_authority_pk.
The exemption exists because the shred-oracle path has no proof it could obtain. crates/sentinel/src/dz_ledger_writer.rs builds CreateSubscribeUser with owner set to the validator and the sentinel as payer. The proof binds the owner (the account the AccessPass is keyed on and the party that operates client_ip), so it would have to name the validator for an address the verification service never sees a request from. Without the exemption, setting the flag would break every oracle-provisioned multicast publisher with IpOwnershipProofRequired (105).
Why this needs revisiting
The exemption is not reachable by a registrant — it requires a DoubleZero-operated key — so it is not the wildcard-pass hole RFC-27 closes. But it is a privileged path that can bind any client_ip without demonstrating control of it, and the residual risk is that a compromised sentinel key can do so silently. Note also that InitGlobalState seeds sentinel_authority_pk to whoever initialized global state, so in a fresh environment the exemption belongs to the deployer until the key is rotated.
Scope
Decide and implement how the oracle path demonstrates IP control, then narrow or remove the exemption. Options, roughly in increasing cost:
- Validator-supplied proof, relayed by the oracle. The validator obtains a proof for its own address out of band and the oracle attaches it. The program already validates a proof the sentinel supplies, so this needs no program change — only a way for the validator to hand a proof to the oracle, and a decision about how long it stays valid (the freshness window is one epoch).
- Narrow the exemption. Restrict it to the multicast-publisher shape the oracle actually creates (
owner_override set, UserType::Multicast) rather than any creation the sentinel pays for.
- Verify at access-pass issuance instead. The oracle already issues the
EdgeSeat pass; if IP control were established there, the user creation would not need a proof at all. This is the "verify at issuance" alternative the RFC considers, applied to just this path.
Acceptance
- The oracle path either carries a real proof or is covered by a deliberately narrowed exemption, documented in the RFC.
- Test coverage for the chosen path with
require-ip-ownership-proof set.
- If the exemption survives in any form,
doublezero permission audit or an equivalent surface reports it, so it is not an invisible privilege.
Part of RFC-27 (rfcs/rfc27-ip-verification.md); tracker #4194.
Context
#4197 added onchain
IpOwnershipProofvalidation toCreateUser/CreateSubscribeUser, gated on therequire-ip-ownership-prooffeature flag. With the flag set, a valid proof is required for every user creation — except when the transaction payer isglobalstate.sentinel_authority_pk.The exemption exists because the shred-oracle path has no proof it could obtain.
crates/sentinel/src/dz_ledger_writer.rsbuildsCreateSubscribeUserwithownerset to the validator and the sentinel as payer. The proof binds the owner (the account the AccessPass is keyed on and the party that operatesclient_ip), so it would have to name the validator for an address the verification service never sees a request from. Without the exemption, setting the flag would break every oracle-provisioned multicast publisher withIpOwnershipProofRequired(105).Why this needs revisiting
The exemption is not reachable by a registrant — it requires a DoubleZero-operated key — so it is not the wildcard-pass hole RFC-27 closes. But it is a privileged path that can bind any
client_ipwithout demonstrating control of it, and the residual risk is that a compromised sentinel key can do so silently. Note also thatInitGlobalStateseedssentinel_authority_pkto whoever initialized global state, so in a fresh environment the exemption belongs to the deployer until the key is rotated.Scope
Decide and implement how the oracle path demonstrates IP control, then narrow or remove the exemption. Options, roughly in increasing cost:
owner_overrideset,UserType::Multicast) rather than any creation the sentinel pays for.EdgeSeatpass; if IP control were established there, the user creation would not need a proof at all. This is the "verify at issuance" alternative the RFC considers, applied to just this path.Acceptance
require-ip-ownership-proofset.doublezero permission auditor an equivalent surface reports it, so it is not an invisible privilege.