{
  "schema_version": "initiative-changes.v1",
  "registry_version": "2026.06.10-8752c9d",
  "initiative_id": "security-readiness",
  "change_count": 4,
  "changes": [
    {
      "schema_version": "initiative-change.v1",
      "id": "security-agent-transaction-safety-surface",
      "initiative_id": "security-readiness",
      "type": "protocol_architecture",
      "status": "watch",
      "summary": "Agent-controlled transactions require explicit authority boundaries, spend limits, replay protection, identity or validation signals, and monitoring before production use.",
      "affected_roles": [
        "ai_agents",
        "agentic_app_builders",
        "security_reviewers",
        "app_builders"
      ],
      "affected_builder_groups": [
        "agent_wallet_builders",
        "agentic_commerce_builders",
        "marketplace_builders",
        "wallet_builders"
      ],
      "affected_protocols": [
        "erc-8004",
        "x402",
        "zerodev",
        "biconomy",
        "safe"
      ],
      "affected_chains": [
        "ethereum",
        "base",
        "arbitrum-one",
        "optimism"
      ],
      "affected_intents": [
        "build-agentic-commerce-with-x402",
        "build-with-smart-accounts",
        "gasless-onboarding"
      ],
      "possible_consequences": [
        "Agent wallets should have bounded permissions, spending policies, replay-safe order IDs, expiry windows, and cancellation or recovery paths.",
        "Payment rails and trust registries do not replace fulfillment, escrow, dispute handling, or incident response for agentic commerce.",
        "Agents should cite whether identity, reputation, validation, payment, and wallet-permission claims come from separate protocols."
      ],
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:erc-8004-eip",
        "official:x402-docs",
        "official:zerodev-permissions"
      ],
      "last_verified_at": "2026-06-10"
    },
    {
      "schema_version": "initiative-change.v1",
      "id": "security-deployment-verification-surface",
      "initiative_id": "security-readiness",
      "type": "external_reference",
      "status": "watch",
      "summary": "Production recommendations should verify chain-specific deployments, contract addresses, source repositories, release provenance, admin controls, and known advisories before claiming support.",
      "affected_roles": [
        "protocol_teams",
        "app_builders",
        "security_reviewers",
        "ai_agents"
      ],
      "affected_builder_groups": [
        "protocol_integrators",
        "multichain_app_builders",
        "registry_maintainers",
        "hackathon_builders"
      ],
      "affected_protocols": [
        "safe",
        "biconomy",
        "zerodev",
        "chainlink",
        "the-graph",
        "gelato",
        "layerzero"
      ],
      "affected_chains": [
        "ethereum",
        "arbitrum-one",
        "base",
        "optimism",
        "polygon",
        "bsc"
      ],
      "affected_intents": [
        "build-with-smart-accounts",
        "gasless-onboarding",
        "build-on-bnb-smart-chain",
        "secure-cross-chain-messaging",
        "real-time-price-feeds"
      ],
      "possible_consequences": [
        "EVM compatibility should not be treated as proof that a protocol has a live, supported, production-ready deployment on a specific chain.",
        "Agents should distinguish docs links, SDK repositories, audited contracts, deployment addresses, source maps, advisories, and release provenance.",
        "Admin keys, upgradeability, pausing, and emergency controls should be reviewed alongside contract addresses before production use."
      ],
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:openzeppelin-contracts-docs",
        "official:safe-docs"
      ],
      "last_verified_at": "2026-06-10"
    },
    {
      "schema_version": "initiative-change.v1",
      "id": "security-paymaster-policy-surface",
      "initiative_id": "security-readiness",
      "type": "protocol_architecture",
      "status": "watch",
      "summary": "Paymaster and gas-sponsorship flows need policy limits, billing controls, abuse monitoring, and fallback behavior before they are safe to expose to users or agents.",
      "affected_roles": [
        "app_builders",
        "wallet_teams",
        "security_reviewers",
        "ai_agents"
      ],
      "affected_builder_groups": [
        "gasless_onboarding_teams",
        "consumer_app_builders",
        "agentic_app_builders",
        "protocol_operations_teams"
      ],
      "affected_protocols": [
        "biconomy",
        "zerodev"
      ],
      "affected_chains": [
        "ethereum",
        "arbitrum-one",
        "base",
        "optimism",
        "polygon",
        "bsc"
      ],
      "affected_intents": [
        "gasless-onboarding",
        "build-with-smart-accounts",
        "build-on-bnb-smart-chain"
      ],
      "possible_consequences": [
        "Sponsored transactions should define who pays, which actions are eligible, how limits are enforced, and what happens when limits are exhausted.",
        "Apps should implement fallback paths for actions that should proceed without sponsorship, and hard failure paths for actions that should never bypass policy.",
        "Agents should not describe gasless UX as free execution without checking quotas, billing, chain support, abuse controls, and paymaster failure modes."
      ],
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:zerodev-sponsor-gas",
        "official:biconomy-docs"
      ],
      "last_verified_at": "2026-06-10"
    },
    {
      "schema_version": "initiative-change.v1",
      "id": "security-smart-account-permission-surface",
      "initiative_id": "security-readiness",
      "type": "protocol_architecture",
      "status": "watch",
      "summary": "Smart-account security depends on owners, validators, modules, session-key permissions, recovery paths, and upgrade or admin authority, not only the wallet SDK.",
      "affected_roles": [
        "wallet_teams",
        "app_builders",
        "security_reviewers",
        "ai_agents"
      ],
      "affected_builder_groups": [
        "smart_account_builders",
        "consumer_wallet_builders",
        "agentic_app_builders",
        "protocol_frontend_teams"
      ],
      "affected_protocols": [
        "safe",
        "biconomy",
        "zerodev",
        "privy"
      ],
      "affected_chains": [
        "ethereum",
        "arbitrum-one",
        "base",
        "optimism",
        "polygon"
      ],
      "affected_intents": [
        "build-with-smart-accounts",
        "gasless-onboarding"
      ],
      "possible_consequences": [
        "Agents should ask for owner model, validator or module choices, recovery assumptions, and target chains before recommending a smart-account path.",
        "Session keys and delegated permissions should include contract allowlists, method allowlists, spend caps, rate limits, and expirations.",
        "Recovery and upgrade authority should be treated as production security surfaces, not onboarding details."
      ],
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "evidence_refs": [
        "official:safe-docs",
        "official:zerodev-permissions",
        "official:openzeppelin-access-control"
      ],
      "last_verified_at": "2026-06-10"
    }
  ]
}