RPC Security Matrix

This page summarizes what each in-page provider RPC is allowed to do and which security checks gate it.

The mapping is derived directly from the extension background script's wallet-provider-handler.handleRpcRequest implementation.

Global invariants

All RPCs share the same outer security envelope:

  • Trusted sender only: Requests must originate from the injected content script running in a top-level tab. Other extensions and extension pages are rejected.
  • Origin allowlist: Only origins on https://*.keeta.com and approved development origins (http://localhost:3000, http://127.0.0.1:3000, http://localhost:3001, http://127.0.0.1:3001, http://localhost:5173, http://127.0.0.1:5173) are served. Non-allowlisted origins are rejected before any RPC handler runs.
  • Origin approval & capabilities:
    • keeta_requestAccounts drives the initial "Connect" approval and grants default capabilities (read + transact) unless a narrower set is requested.
    • Most protected RPCs require the origin to be approved and to hold the relevant capability (read, sign, transact, network).
    • Many RPCs also require a capability token bound to that capability, passed in the last parameter position.

Legend

  • Origin: whether the origin must be merely allowlisted or fully approved (via connect).
  • Caps: capability flags required (read, sign, transact, network).
  • Token: whether a capability token must be provided and which capability it's bound to.
  • User flow: whether a visible UI flow is required at call time (connect dialog, network switch approval, transaction/signature approval, builder approval).

Public & connection RPCs

These RPCs are reachable from any allowlisted origin, even before the origin is connected.

MethodOriginCapsTokenUser flowNotes
keeta_getAccountsallowlisted onlynonenonenoneReturns [] until the origin has been approved. After connect, returns current wallet accounts and updates last-used timestamp.
keeta_isLockedallowlisted onlynonenonenoneExposes wallet lock state as true / false (or true if state is unavailable). Does not reveal account data.
keeta_requestAccountsallowlisted → approvedread + requested (default read+transact)internalConnect dialog per originDrives the connection approval UI. Ensures the origin is allowlisted, obtains explicit approval, and grants the requested capabilities.

Capability & network RPCs

Capability management and network selection are protected and require prior origin approval.

MethodOriginCapsTokenUser flowNotes
keeta_requestCapabilitiesapprovedrequested set (read / sign / transact / network)mints tokensMay show capability approval UI when new scopes are requestedEnsures the origin holds the requested capabilities and returns fresh capability tokens for them.
keeta_refreshCapabilitiesapprovedrequested setrefreshes tokensbackgroundRefreshes existing capability tokens for an already-approved origin. Does not expand scope.
keeta_getNetworkapprovedreadrequired (read, param 0)noneReturns the active Keeta network and touches origin activity.
keeta_switchNetworkapprovednetworkrequired (network, param 1)Network switch approvalQueues a network-switch request (per-origin approval) and only applies the change after user confirmation in the wallet UI.

Read RPCs (post-connect)

These endpoints expose data but do not modify on-chain or wallet state. Most require the read capability and, in some cases, a read capability token.

MethodOriginCapsTokenUser flowNotes
keeta_getAccountapprovedreadrequired (read, param 0)noneReturns the wallet's primary Keeta account reference for the user.
keeta_getBalanceapprovedreadrequired (read, param 1)noneReturns balance for an address (param 0). Requires the wallet to be unlocked for balance access and caches the result per origin.
keeta_getAllBalancesapprovedreadrequired (read, param 0)noneReturns all balances for the active wallet account; cached per origin.
keeta_getNormalizedBalancesapprovedreadrequired (read, param 0)noneReturns normalized token balances; on failure emits BALANCE_UNAVAILABLE.
keeta_getAccountStateapprovedreadnonenoneReturns on-chain state (info, metadata, balances, raw state) for any Keeta account. Normalizes account public keys and handles SDK errors.
keeta_getNetworkInfoapprovedreadnonenoneReturns static network configuration/details via the Keeta SDK.
keeta_getBaseTokenapprovedreadnonenoneReturns the base token descriptor for the active network.
keeta_getAccountInfoapprovednonenonenoneRead-only account info helper. Requires origin approval but no explicit capability token.
keeta_listStorageAccountsByOwnerapprovednonenonenoneLists storage accounts by owner address. Requires only origin approval.
keeta_getKtaPriceapprovednonenonenoneReturns current KTA price via the wallet's pricing integration.

History RPCs: keeta_getHistory and keeta_getActivity are intentionally removed and always return UNSUPPORTED_METHOD. Use the Keeta JS SDK (ledger history APIs) or an indexer service instead.

Write RPCs (transactions, signatures, token admin)

All write operations share the following requirements:

  • Origin must be allowlisted and approved.
  • The origin must hold the appropriate capability (transact or sign).
  • A valid, non-expired capability token for that capability is required where noted.
  • State-changing actions run through a per-operation approval flow in the wallet UI.
MethodOriginCapsTokenUser flowNotes
keeta_sendTransactionapprovedtransactrequired (transact, param 1)Transaction approvalSends a raw transaction object via the Keeta SDK. The wallet validates the payload and queues a user-facing approval before broadcasting.
keeta_signMessageapprovedsignrequired (sign, param 1)Signing approvalSigns arbitrary messages. A phishing detection helper runs over the message before the approval UI is shown, and security warnings are logged.
keeta_sendapprovedtransactrequired (transact, param 3)Transaction approvalConvenience wrapper for sends: (recipient, amount, token, capabilityToken).
keeta_receiveapprovedtransactrequired (transact, param 3)Transaction approvalConvenience receive helper: (sender, amount, token, capabilityToken).
keeta_createTokenapprovedtransactrequired (transact, param 5)Transaction approvalCreates a token (name, symbol, decimals, initial supply, access mode). The wallet builds and publishes the underlying Keeta operations.
keeta_modifyTokenSupplyapprovedtransactrequired (transact, param 3)Transaction approvalMints/burns supply for an existing token. Internal safeguards prevent misuse of the user's keyed account during token creation flows.
keeta_modifyTokenBalanceapprovedtransactrequired (transact, param 3)Transaction approvalDirect balance adjustment where the network permissions allow it.
keeta_updatePermissionsapprovedtransactrequired (transact, param 3)Transaction approvalUpdates Keeta base or external permissions on an account (including STORAGE/TOKEN resource permissions).
keeta_setInfoapprovedtransactrequired (transact, param 2)Transaction approvalUpdates account info/metadata (name, description, metadata, default permissions, etc.).
keeta_createStorageAccountapprovedtransactrequired (transact, param 4)Transaction approvalCreates storage accounts. Also intercepted inside builder flows for consistent approval and validation.

User client & builder RPCs

These RPCs expose a higher-level Keeta SDK surface (user client + builder). They still enforce origin approval and the transact capability but generally do not require capability tokens directly.

MethodOriginCapsTokenUser flowNotes
keeta_getUserClientapprovedtransactnonenone (fails if locked)Verifies that a Keeta UserClient can be constructed. Returns { success: true } only when the wallet is unlocked; otherwise throws UNAUTHORIZED.
keeta_builder_generateIdentifierapprovedtransactnonenoneGenerates NETWORK/TOKEN/STORAGE identifiers via the Keeta builder and returns a serializable account reference.
keeta_builder_computeBlocksapprovedtransactnonenone (approval happens at publish)Computes blocks for a list of builder operations. Includes additional validation for token operations and serializes block bytes and hashes for debugging.
keeta_builder_publishapprovedtransactnoneBuilder approval for state-changing opsPublishes builder operations. Storage creation is intercepted into the dedicated storage-account flow; send/receive/token/permission operations still require the usual transaction approvals and are logged for activity.

How to use this matrix

  • When designing a new flow, pick the minimal capability set your dApp needs (read vs read+transact vs read+sign+network).
  • Use keeta_requestAccounts once to connect, then keeta_requestCapabilities / keeta_refreshCapabilities to manage capability tokens over time.
  • For security reviews, verify every wallet call in your dApp matches the capabilities + tokens documented here and surface clear, user-centric UI whenever a visible wallet approval will be triggered.