Metamask - EIP-7715 Permissions Snap

1 Executive Summary

This report presents the results of our engagement with MetaMask to review the Gator 7715 Permissions & Kernel Snap.

The review was conducted over 3 calendar weeks, from Aug 11, 2025 to Aug 29, 2025, with a total effort of 4.5 person-weeks, with one reviewer for 3 person-weeks and another with 1.5 person-weeks.

The system enables users to grant time-bound, caveat-restricted permissions for various blockchain operations including ERC-20 token transfers, native token operations, and streaming payments. Through its integration with DeleGator smart accounts and the delegation toolkit, it provides a foundation for automated, user-controlled blockchain interactions while maintaining security through comprehensive validation and user consent mechanisms.

The MetaMask Gator Permissions Snap is an EIP-7715 permissions management system that enables granular control over blockchain permissions through MetaMask’s Snap framework. This dual-snap architecture consists of the Gator Permissions Snap and the Permissions Kernel Snap, working together to implement EIP-7715 for delegated permissions and smart account interactions.

The Permission Kernel Snap implements a registry intended to support multiple 7715-compliant adapters in the future. At present, however, it is hardcoded to the Gator Permission Snap Adapter. While this reduces the kernel’s direct attack surface, it simultaneously increases the system’s overall exposure, since snap-to-snap communication introduces additional complexity and requires safeguards such as whitelisting, a broker model, and forwarding of the original origin.

The Gator Permission Snap is configured to allow communication from the Kernel Snap (the “router”) and MetaMask internal wallet operations only. The Kernel as the request broker can ask for all offered permissions and request specific permissions requested by a DApp. The adapter also offers a getter to return all issued permissions that can only be accessed by MetaMask.

Update: October 28, 2025 - Mitigations Review

Between October 22, 2025 and October 28, 2025, we conducted a review of the client’s remediation measures implemented in commit 476e653 of the MetaMask/snap-7715-permissions repository.

Update: October 30, 2025 - Additional Mitigations Review

Removed viem dependency with 6da514a.

2 Scope

This review focused on the following repository and code revision:

• MetaMask/snap-7715-permissions ( 2917e66247c44bafefc51514eb2eee5339b34455)

Third party dependencies packages are out of scope for this review.

The detailed list of files in scope can be found in the Appendix.

2.1 Objectives

Together with client, we identified the following priorities for this review:

1. Correctness of the implementation, consistent with the intended functionality and without unintended edge cases.
2. Identify vulnerabilities particular to the MetaMask Snaps SDK integration in coherence with the MetaMask Snap Security Guidelines and Threat Model describing a Snap as an extension of the MetaMask Wallet Trust Module.

3 Snap Configuration Overview

As part of the assessment, the following key aspects of the Snap’s configuration were identified:

3.1 EIP-7715 Permissions Kernel Snap

• The Snap serves as a permissions kernel implementing EIP-7715 for managing execution permissions in the MetaMask ecosystem.
• It acts as an intermediary that receives permission requests from DApps and routes them to appropriate permission providers (currently the Gator Permissions Provider Snap).
• The Snap is designed to support multiple permission providers in the future but currently integrates specifically with the GATOR_PERMISSIONS_PROVIDER_SNAP_ID.
• The Snap is state-less and only serves hard-coded adapters from the registry.

Internal Architecture:

• Registry Manager: Manages the permission offer registry and handles finding relevant permissions to grant from available offers.
• RPC Handler: Processes incoming RPC requests and orchestrates the permission granting workflow.

RPC Methods:

• wallet_requestExecutionPermissions: The primary method exposed to DApps for requesting execution permissions. This method:
  • Parses and validates the permission request
  • Builds a permission offers registry from the Gator permissions provider
  • Finds relevant permissions to grant by filtering against registered offers
  • Invokes the permission provider snap to grant attenuated permissions
  • Returns the granted permissions to the requesting DApp

Snap Permissions:

• snap_dialog: Displays dialogs in the MetaMask UI ⚠️
• endowment:rpc:
  • dapps: true - Allows communication with websites/DApps
  • snaps: true - Enables communication with other snaps ⚠️

DApp Connectivity and Permissions:

• Connected DApp communicate with the Snap via RPC calls. Any connected DApp can communicate with the Snap. No restrictions or programmatic whitelists.
• Development origins are not explicitly excluded from initial-connections for production builds ⚠️
• The snap allows DApp-to-Snap and Snap-to-Snap. It is unclear if the latter is actually needed ⚠️

State Management:

• No state information is stored or accessed.

Dependencies:

• @metamask/snaps-sdk:8.1.0 (marked as potential dev dependency)
• viem:2.31.7 ⚠️

Origin Permissions

  "initialConnections": {
    "local:http://localhost:8082": {},
    "npm:@metamask/gator-permissions-snap": {}
  },
  "initialPermissions": {
    "snap_dialog": {},
    "endowment:rpc": {
      "dapps": true,
      "snaps": true
    }

• Development origin whitelisted at initialConnections ⚠️
• Trusting gator-permissions-snap via initialConnections might not be needed ⚠️

Details

----%<---- raw permissions
🌐 : https://docs.metamask.io/snaps/reference/rpc-api/#wallet_requestsnaps
snap_dialog {}
endowment:rpc { dapps: true, snaps: true }
---->%---- raw permissions
🚜 [snap_dialog]
    ☝️ - snap_dialog - Displays a dialog in the MetaMask UI. There are three types of dialogs with different parameters and return types.
    ⚠️ - this method renders Markdown! check for ctrlchar/markdown/injection
       🔸  src/index.ts
🚜 [endowment:rpc]
    ❗- endowment:rpc.dapps - snap can communicate with websites/dapps; check origin for internal api calls!
    ⚠️ - endowment:rpc.snaps - snap can communicate with other snaps; check origin for internal api calls!
       🔸  src/index.ts
🌲 - Package Dependencies:
      - @metamask/snaps-sdk:8.1.0                (🔺 looks like devDependency 👀)
      - viem:2.31.7
[🚀 == Metrics == ]
👉 316 (lines of code)

3.2 Gator Permissions Snap

• The Snap serves as a permissions provider implementing EIP-7715 for managing token spending permissions in the MetaMask ecosystem.
• It acts as the core permissions provider that receives permission requests from the EIP-7715 Permissions Kernel Snap and manages the full lifecycle of permission granting, validation, and storage.
• The Snap implements four types of token permissions: ERC-20 Token Stream, ERC-20 Token Periodic, Native Token Stream, and Native Token Periodic.
• The Snap maintains persistent state of granted permissions and provides a management interface for users to view their active permissions.

This is currently the only adapter that Kernel interfaces with.

Internal Architecture:

• Permission Handler Factory: Creates specialized handlers for different permission types with validation rules and UI content generation.
• Permission Request Lifecycle Orchestrator: Manages the complete permission request workflow from validation through user confirmation to delegation creation.
• Confirmation Dialog System: Handles user consent dialogs with dynamic content based on permission type and context.
• Account Controller: Manages EOA account operations and EIP-712 delegation signing for permission enforcement.
• Profile Sync Manager: Persists granted permissions across browser sessions using MetaMask’s profile sync functionality.
• Token Metadata & Pricing Services: Fetches external token information and real-time pricing data for UI display.

RPC Methods:

• grantPermission: The primary method for processing permission requests. This method:
  • Validates incoming permission requests against defined schemas
  • Creates appropriate permission handlers based on request type
  • Orchestrates user confirmation dialogs showing origin, token details, and permission scope
  • Creates EIP-712 delegations for approved permissions
  • Stores granted permissions for future reference
• getPermissionOffers: Returns available permission types that can be granted
• getGrantedPermissions: Retrieves all previously granted permissions for management purposes

Snap Permissions:

• endowment:rpc: Enables communication with other snaps (specifically the EIP-7715 Permissions Kernel) ⚠️
• snap_manageState: Stores granted permissions and user preferences (up to 100MB isolated storage)
• endowment:ethereum-provider: Accesses Ethereum API for account operations and delegation signing ⚠️
• endowment:network-access: Makes HTTP requests to external APIs for token metadata and pricing ⚠️
• snap_dialog: Displays permission confirmation and management dialogs ⚠️
• endowment:lifecycle-hooks: Handles installation and homepage events
• snap_getPreferences: Accesses user preferences for currency and locale settings
• endowment:page-home: Provides homepage interface for permission management

DApp Connectivity and Permissions:

• The Snap does not directly communicate with DApps (dapps: false in RPC endowment).
• All DApp interactions are mediated through the EIP-7715 Permissions Kernel Snap for security isolation.
• Development origins are not explicitly restricted in production builds (manifest), however, they are excluded from the programmatic permission check ⚠️
• The snap allows Snap-to-Snap communication. npm:@metamask/permissions-kernel-snap is trusted by default.

State Management:

• Persistent storage of granted permissions with origin tracking and expiration management.
• Token metadata caching for improved performance and reduced external API calls.
• User preference synchronization across MetaMask installations via profile sync.

Dependencies:

• @metamask/snaps-sdk:8.1.0 (Core Snaps functionality)
• @metamask/delegation-core:0.2.0-rc.1 (EIP-712 delegation creation)
• @metamask/utils:11.4.2 (Utility functions for CAIP parsing and validation)
• viem:2.31.7 (Ethereum interactions) ⚠️ unused
• zod:3.25.76 (Runtime validation and type safety)

Origin Permissions

  "initialConnections": {
    "local:http://localhost:8081": {},
    "npm:@metamask/permissions-kernel-snap": {}
  },
  "initialPermissions": {
    "endowment:rpc": {
      "dapps": false,
      "snaps": true
    },
    "snap_manageState": {},
    "endowment:ethereum-provider": {},
    "endowment:network-access": {},
    "snap_getEntropy": {},
    "snap_dialog": {},
    "endowment:lifecycle-hooks": {},
    "snap_getPreferences": {},
    "endowment:page-home": {}
  },

• Development origin whitelisted at initialConnections ⚠️
• Network access enabled for external API calls to token metadata and pricing services ⚠️
• Ethereum provider access for delegation signing and account operations ⚠️

Details

----%<---- raw permissions
🌐 : https://docs.metamask.io/snaps/reference/rpc-api/#wallet_requestsnaps
endowment:rpc { dapps: false, snaps: true }
snap_manageState {}
endowment:ethereum-provider {}
endowment:network-access {}
snap_getEntropy {}
snap_dialog {}
endowment:lifecycle-hooks {}
snap_getPreferences {}
endowment:page-home {}
---->%---- raw permissions
🚜 [endowment:rpc]
    ⚠️ - endowment:rpc.snaps - snap can communicate with other snaps; check origin for internal api calls!
       🔸  src/index.ts
🚜 [snap_manageState]
    🪤 - snap_manageState - snap can store up to 100mb (isolated)
       🔸  src/stateManagement.ts
🚜 [endowment:ethereum-provider]
    🔺 - endowment:ethereum-provider - snap can access ethereum API
    ⚠️ - check if the **snap code** (not site) actually accesses the global 'ethereum' object
see https://docs.metamask.io/snaps/learn/about-snaps/apis/#snap-requests
       🔸  src/clients/priceApiClient.ts
🚜 [endowment:network-access]
    🌐 - endowment:network-access - snap can access internet
     ⚠️ - this method may leak information to external api
🚜 [snap_getEntropy]
    ✨ - snap_getEntropy - Gets a deterministic 256-bit entropy value, specific to the snap and the user's account. You can use this entropy to generate a private key, or any other value that requires a high level of randomness. Other snaps can't access this entropy, and it changes if the user's secret recovery phrase changes.
       🔺 - superfluous permission: no reference to 'snap_getEntropy'!
🚜 [snap_dialog]
    ☝️ - snap_dialog - Displays a dialog in the MetaMask UI. There are three types of dialogs with different parameters and return types.
    ⚠️ - this method renders Markdown! check for ctrlchar/markdown/injection
       🔸  src/homepage/index.tsx
       🔸  src/core/confirmation.tsx
🚜 [endowment:lifecycle-hooks]
    🔺 - endowment:lifecycle-hooks - unknown permission requested
🚜 [snap_getPreferences]
    🔺 - snap_getPreferences - unknown permission requested
🚜 [endowment:page-home]
    🔺 - endowment:page-home - unknown permission requested
🌲 - Package Dependencies:
      - @metamask/abi-utils:3.0.0                (🔺 looks like devDependency 👀)
      - @metamask/delegation-core:0.2.0-rc.1             (🔺 looks like devDependency 👀)
      - @metamask/delegation-toolkit:0.10.2              (🔺 looks like devDependency 👀)
      - @metamask/profile-sync-controller:21.0.0                 (🔺 looks like devDependency 👀)
      - @metamask/snaps-sdk:8.1.0                (🔺 looks like devDependency 👀)
      - @metamask/utils:11.4.2           (🔺 looks like devDependency 👀)
      - viem:2.31.7
      - zod:3.25.76
[🚀 == Metrics == ]
...
👉 6926 (lines of code)

4 General Findings

Each issue has an assigned severity:

• Critical issues are directly exploitable security vulnerabilities that need to be fixed.
• Major issues are security vulnerabilities that may not be directly exploitable or may require certain conditions in order to be exploited. All major issues should be addressed.
• Medium issues are objective in nature but are not security vulnerabilities. These should be addressed unless there is a clear reason not to.
• Minor issues are subjective in nature. They are typically suggestions around best practices or readability. Code maintainers should use their own judgment as to whether to address such issues.
• Issues without a severity are general recommendations or optional improvements. They are not related to security or correctness and may be addressed at the discretion of the maintainer.

"initialConnections": {
  "local:http://localhost:8081": {},
  "npm:@metamask/permissions-kernel-snap": {}
},

"initialConnections": {
  "local:http://localhost:8082": {},
  "npm:@metamask/gator-permissions-snap": {}

export const onRpcRequest: OnRpcRequestHandler = async ({
  origin,
  request,
}) => {
  logger.info(
    `Custom request (origin="${origin}"):`,
    JSON.stringify(request, undefined, 2),
  );

  const handler = boundRpcHandlers[request.method];

async function buildPermissionOffersRegistry(
  snapId: string,
): Promise<PermissionOfferRegistry> {
  let ephemeralPermissionOfferRegistry: PermissionOfferRegistry = {};
  try {
    try {
      logger.debug(`Querying snap ${snapId} for permission offers...`);

      const response = await snapsProvider.request({
        method: 'wallet_invokeSnap',
        params: {
          snapId,
          request: {
            method: ExternalMethod.PermissionProviderGetPermissionOffers,
          },
        },
      });

      if (response) {
        const parsedOffers = parsePermissionOffersParam(response);
        const uniqueOffersToStore: RegisteredPermissionOffers =
          parsedOffers.map((offer) => {
            return {
              hostId: snapId,
              type: offer.type,
              proposedName: offer.proposedName,
            };
          });

        ephemeralPermissionOfferRegistry = {
          ...ephemeralPermissionOfferRegistry,
          [snapId]: uniqueOffersToStore,
        };

        logger.debug(
          `Snap ${snapId} supports ${ExternalMethod.PermissionProviderGetPermissionOffers}, adding to registry...`,
        );
      }
    } catch (error) {
      logger.error(
        {
          snapId,
          error,
        },
        `Snap ${snapId} does not support ${ExternalMethod.PermissionProviderGetPermissionOffers}, or returned an invalid response, skipping...`,
      );
    }

    return ephemeralPermissionOfferRegistry;
  } catch (error) {
    logger.error('Error building permission offer registry:', error);
    return ephemeralPermissionOfferRegistry;
  }

export const onRpcRequest: OnRpcRequestHandler = async ({
  origin,
  request,
}) => {
  logger.debug(
    `RPC request (origin="${origin}"):`,
    JSON.stringify(request, undefined, 2),
  );

async getCryptoToFiatConversion(
  tokenCaip19Type: CaipAssetType,
  balance: Hex,
  decimals: number,
): Promise<string> {
  try {
    logger.debug('TokenPricesService:getCryptoToFiatConversion()');
    const preferences = await this.#getPreferences();

    // Value in fiat=(Amount in crypto)×(Spot price)
    const tokenSpotPrice = await this.#priceApiClient.getSpotPrice(
      tokenCaip19Type,
      this.#safeParsePreferences(preferences),
    );
    const formattedBalance = Number(
      formatUnits({ value: BigInt(balance), decimals }),
    );
    const valueInFiat = formattedBalance * tokenSpotPrice;

    const humanReadableValue = formatAsCurrency(preferences, valueInFiat);
    logger.debug(
      'TokenPricesService:formatAsCurrency() - formatted balance to currency',
      humanReadableValue,
    );

    return humanReadableValue;
  } catch (error) {
    logger.error(
      'TokenPricesService:getCryptoToFiatConversion() - failed to fetch token spot price',
      error,
    );

    // TODO: Return a more user-friendly error message so failed calls to the Price API are handled gracefully
    // and do not make the entire permission request fail. We can use cached prices as a fallback to prevent this issue message in UI.
    return '$<-->';
  }

5 Findings: Kernel

/**
 * Handle incoming JSON-RPC requests, sent through `wallet_invokeSnap`.
 *
 * @param args - The request handler args as object.
 * @param args.origin - The origin of the request, e.g., the website that
 * invoked the snap.
 * @param args.request - A validated JSON-RPC request object.
 * @returns The result of `snap_dialog`.
 * @throws If the request method is not valid for this snap.
 */
export const onRpcRequest: OnRpcRequestHandler = async ({
  origin,
  request,
}) => {
  logger.info(
    `Custom request (origin="${origin}"):`,
    JSON.stringify(request, undefined, 2),
  );

  const handler = boundRpcHandlers[request.method];

  if (!handler) {
    throw new Error(`Method ${request.method} not found.`);
  }

// set up dependencies
const rpcHandler = createRpcHandler({
  permissionOfferRegistryManager: createPermissionOfferRegistryManager(snap),
  snapsProvider: snap,
});

// configure RPC methods bindings
const boundRpcHandlers: {
  [RpcMethod: string]: (options: {
    siteOrigin: string;
    params?: JsonRpcParams;
  }) => Promise<Json>;
} = {
  [RpcMethod.WalletRequestExecutionPermissions]:
    rpcHandler.requestExecutionPermissions.bind(rpcHandler),
};

"initialConnections": {
  "local:http://localhost:8082": {},
  "npm:@metamask/gator-permissions-snap": {}
},
"initialPermissions": {
  "snap_dialog": {},
  "endowment:rpc": {
    "dapps": true,
    "snaps": true
  }
},

"dependencies": {
  "@metamask/snaps-sdk": "8.1.0",
  "viem": "2.31.7"
},

/**
 * Handle incoming JSON-RPC requests, sent through `wallet_invokeSnap`.
 *
 * @param args - The request handler args as object.
 * @param args.origin - The origin of the request, e.g., the website that
 * invoked the snap.
 * @param args.request - A validated JSON-RPC request object.
 * @returns The result of `snap_dialog`.
 * @throws If the request method is not valid for this snap.
 */

/**
 * Handle incoming JSON-RPC requests, sent through `wallet_invokeSnap`.
 *
 * @param args - The request handler args as object.
 * @param args.origin - The origin of the request, e.g., the website that
 * invoked the snap.
 * @param args.request - A validated JSON-RPC request object.
 * @returns The result of `snap_dialog`.
 * @throws If the request method is not valid for this snap.
 */
export const onRpcRequest: OnRpcRequestHandler = async ({
  origin,
  request,
}) => {
  logger.info(
    `Custom request (origin="${origin}"):`,
    JSON.stringify(request, undefined, 2),
  );

  const handler = boundRpcHandlers[request.method];

  if (!handler) {
    throw new Error(`Method ${request.method} not found.`);
  }

  const result = await handler({
    siteOrigin: origin,
    params: request.params as JsonRpcParams,
  });

  return result;
};

/**
 * Flattens the permission offer registry into a single array of registered permission offers.
 *
 * @param permissionOfferRegistry - The permission offer registry to flatten.
 * @returns The registered permission offers.
 */
function getRegisteredPermissionOffers(
  permissionOfferRegistry: PermissionOfferRegistry,
): RegisteredPermissionOffers {
  if (Object.keys(permissionOfferRegistry).length === 0) {
    return [];
  }

  return Object.values(permissionOfferRegistry).reduce(
    (acc, offers) => [...acc, ...offers],
    [],
  );
}

6 Findings: Gator

export const FALLBACK_PREFERENCE: Preferences = {
  locale: 'en',
  currency: 'USD',
};

#safeParsePreferences(preferences: Preferences): VsCurrencyParam {
  const { currency, locale } = preferences;
  return locale === 'en'
    ? (currency.toLowerCase() as VsCurrencyParam)
    : (FALLBACK_PREFERENCE.currency.toLowerCase() as VsCurrencyParam);
}

const preferences = await this.#getPreferences();

// Value in fiat=(Amount in crypto)×(Spot price)
const tokenSpotPrice = await this.#priceApiClient.getSpotPrice(
  tokenCaip19Type,
  this.#safeParsePreferences(preferences),
);
const formattedBalance = Number(
  formatUnits({ value: BigInt(balance), decimals }),
);
const valueInFiat = formattedBalance * tokenSpotPrice;

const humanReadableValue = formatAsCurrency(preferences, valueInFiat);
logger.debug(
  'TokenPricesService:formatAsCurrency() - formatted balance to currency',
  humanReadableValue,
);

"snap_getEntropy": {},

const response = await this.#fetch(
  `${this.#baseUrl}/tokens/${tokenAddress}?accountAddresses=${account}&chainId=${chainId}`,
);

if (!response.ok) {
  const message = `HTTP error. Failed to fetch token balance for account(${account}) and token(${tokenAddress}) on chain(${chainId}): ${response.status}`;
  logger.error(message);

  throw new Error(message);
}

const { accounts, type, iconUrl, symbol, decimals } =
  (await response.json()) as TokenBalanceResponse;

const accountLowercase = account.toLowerCase();
const accountData = accounts.find(
  (acc) => acc.accountAddress.toLowerCase() === accountLowercase,
);

const response = await this.#fetch(
  `${
    this.#baseUrl
  }/v3/spot-prices?includeMarketData=false&vsCurrency=${vsCurrency}&assetIds=${caipAssetType}`,
);

if (!response.ok) {
  logger.error(
    `HTTP error! Failed to fetch spot price for caipAssetType(${caipAssetType}) and vsCurrency(${vsCurrency}): ${response.status}`,
  );
  throw new Error(
    `HTTP error! Failed to fetch spot price for caipAssetType(${caipAssetType}) and vsCurrency(${vsCurrency}): ${response.status}`,
  );
}

const spotPricesRes = (await response.json()) as SpotPricesRes;

const assetTypeData = spotPricesRes[caipAssetType];
if (!assetTypeData) {
  logger.error(
    `No spot price found in result for the token CAIP-19 asset type: ${caipAssetType}`,
  );
  throw new Error(
    `No spot price found in result for the token CAIP-19 asset type: ${caipAssetType}`,
  );
}

const vsCurrencyData = assetTypeData[vsCurrency];
if (!vsCurrencyData) {
  logger.error(
    `No spot price found in result for the currency: ${vsCurrency}`,
  );
  throw new Error(
    `No spot price found in result for the currency: ${vsCurrency}`,
  );
}
return vsCurrencyData;

/**
 * Retrieve all granted permission items under the "7715_permissions" feature will result in GET /api/v1/userstorage/7715_permissions
 * VALUES: decrypted("JSONstringifyPermission1", storage_key), decrypted("JSONstringifyPermission2", storage_key).
 * @returns All granted permissions.
 */
async function getAllGrantedPermissions(): Promise<
  StoredGrantedPermission[]
> {
  try {
    await authenticate();

    const items = await userStorage.getAllFeatureItems(FEATURE);
    return (
      items?.map((item) => JSON.parse(item) as StoredGrantedPermission) ?? []
    );
  } catch (error) {
    logger.error('Error fetching all granted permissions:', error);
    throw error;
  }
}

async function getGrantedPermission(
  permissionContext: Hex,
): Promise<StoredGrantedPermission | null> {
  try {
    await authenticate();

    const path: UserStorageGenericPathWithFeatureAndKey = `${FEATURE}.${generateObjectKey(permissionContext)}`;
    const permission = await userStorage.getItem(path);

    return permission
      ? (JSON.parse(permission) as StoredGrantedPermission)
      : null;
  } catch (error) {
    logger.error('Error fetching granted permissions:', error);
    throw error;
  }

/**
 * Store the granted permission in profile sync.
 *
 * Persisting "<permissionContext>" key under "gator_7715_permissions" feature
 * value has to be serialized to string and does not exceed 400kb
 * it is up to the SDK consumer to enforce proper schema management
 * will result in PUT /api/v1/userstorage/gator_7715_permissions/Hash(<storage_key+<permissionContext>">)
 * VALUE: encrypted("JSONstringifyPermission", storage_key).
 * @param storedGrantedPermission - The permission response to store.
 */
async function storeGrantedPermission(
  storedGrantedPermission: StoredGrantedPermission,
): Promise<void> {
  try {
    await authenticate();

    const path: UserStorageGenericPathWithFeatureAndKey = `${FEATURE}.${generateObjectKey(storedGrantedPermission.permissionResponse.context)}`;
    await userStorage.setItem(path, JSON.stringify(storedGrantedPermission));
  } catch (error) {
    logger.error('Error storing granted permission:', error);
    throw error;
  }
}

// Batch request: [Permission A, Permission B, Permission C]
// Execution flow:
// 1. Permission A: ✅ Signed → ✅ Stored → ✅ Success
// 2. Permission B: ✅ Signed → ✅ Stored → ✅ Success 
// 3. Permission C: ✅ Signed → ❌ Storage Fails → 💥 Promise.all REJECTS

// Result: Permissions A & B are stored but NEVER returned to dApp
// Impact: Orphaned permissions in storage, inconsistent dApp state

/**
 * Handles grant permission requests.
 *
 * @param params - The parameters for the grant permission request.
 * @returns The result of the grant permission request.
 */
const grantPermission = async (params?: Json): Promise<Json> => {
  logger.debug('grantPermissions()', params);
  const { permissionsRequest, siteOrigin } =
    validatePermissionRequestParam(params);

  const responses = await Promise.all(
    permissionsRequest.map(async (request) => {
      const handler =
        permissionHandlerFactory.createPermissionHandler(request);

      const permissionResponse =
        await handler.handlePermissionRequest(siteOrigin);

      if (!permissionResponse.approved) {
        throw new Error(permissionResponse.reason);
      }

      if (permissionResponse.response) {
        await profileSyncManager.storeGrantedPermission({
          permissionResponse: permissionResponse.response,
          siteOrigin,
        });
      }

      return permissionResponse.response;
    }),
  );

  return responses as Json[];

export const onInstall: OnInstallHandler = async () => {
  /**
   * Local Development Only
   *
   * The message signing snap must be installed and the gator permissions snap must
   * have permission to communicate with the message signing snap, or the request is rejected.
   *
   * Since the message signing snap is preinstalled in production, and has
   * initialConnections configured to automatically connect to the gator snap, this is not needed in production.
   */
  // eslint-disable-next-line no-restricted-globals
  if (snapEnv === 'local' && isStorePermissionsFeatureEnabled) {
    const installedSnaps = (await snap.request({
      method: 'wallet_getSnaps',
    })) as unknown as GetSnapsResponse;
    if (!installedSnaps[MESSAGE_SIGNING_SNAP_ID]) {
      logger.debug('Installing local message signing snap');
      await snap.request({
        method: 'wallet_requestSnaps',
        params: {
          [MESSAGE_SIGNING_SNAP_ID]: {},
        },
      });
    }
  }

  await homepage.showWelcomeScreen();
};

public async getNonce({
  chainId,
  account,
}: {
  chainId: number;
  account: Hex;
}): Promise<bigint> {
  logger.debug('BlockchainTokenMetadataClient:getTokenBalanceAndMetadata()');

  if (!chainId) {
    const message = 'No chainId provided to fetch nonce';
    logger.error(message);
    throw new Error(message);
  }

export const TokenIcon: SnapComponent<TokenIconParams> = ({
  imageDataBase64,
  altText,
  width = 24,
  height = 24,
}) => {
  if (!imageDataBase64) {
    return <Text> </Text>;
  }

  const imageSvg = `<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24">
    <image href="${imageDataBase64}" width="${width}" height="${height}" />
  </svg>`;

7 Document Change Log

Appendix 1 - Files in Scope

This review covered the following files:

Appendix 2 - Disclosure

Consensys Diligence (“CD”) typically receives compensation from one or more clients (the “Clients”) for performing the analysis contained in these reports (the “Reports”). The Reports may be distributed through other means, including via Consensys publications and other distributions.

The Reports are not an endorsement or indictment of any particular project or team, and the Reports do not guarantee the security of any particular project. This Report does not consider, and should not be interpreted as considering or having any bearing on, the potential economics of a token, token sale or any other product, service or other asset. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. No Report provides any warranty or representation to any third party in any respect, including regarding the bug-free nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third party should rely on the Reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other asset. Specifically, for the avoidance of doubt, this Report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project. CD owes no duty to any third party by virtue of publishing these Reports.

A.2.1 Purpose of Reports

The Reports and the analysis described therein are created solely for Clients and published with their consent. The scope of our review is limited to a review of code and only the code we note as being within the scope of our review within this report. Any Solidity code itself presents unique and unquantifiable risks as the Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond specified code that could present security risks. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. In some instances, we may perform penetration testing or infrastructure assessments depending on the scope of the particular engagement.

CD makes the Reports available to parties other than the Clients (i.e., “third parties”) on its website. CD hopes that by making these analyses publicly available, it can help the blockchain ecosystem develop technical best practices in this rapidly evolving area of innovation.

A.2.2 Links to Other Web Sites from This Web Site

You may, through hypertext or other computer links, gain access to web sites operated by persons other than Consensys and CD. Such hyperlinks are provided for your reference and convenience only, and are the exclusive responsibility of such web sites’ owners. You agree that Consensys and CD are not responsible for the content or operation of such Web sites, and that Consensys and CD shall have no liability to you or any other person or entity for the use of third party Web sites. Except as described below, a hyperlink from this web Site to another web site does not imply or mean that Consensys and CD endorses the content on that Web site or the operator or operations of that site. You are solely responsible for determining the extent to which you may use any content at any other web sites to which you link from the Reports. Consensys and CD assumes no responsibility for the use of third-party software on the Web Site and shall have no liability whatsoever to any person or entity for the accuracy or completeness of any outcome generated by such software.

A.2.3 Timeliness of Content

The content contained in the Reports is current as of the date appearing on the Report and is subject to change without notice unless indicated otherwise, by Consensys and CD.