The following is pasted directly from the docs/docs/get-started/llm-intro.md file, and should be

replaced as that file is updated.

MetaMask Delegation Toolkit LLM introduction

The following text is a condensed introduction to the MetaMask Delegation Toolkit, for use in an
LLM's limited context.

Copy the following text by selecting the copy icon in the upper right corner of the text block:

This is a software toolkit for developing applications for the Ethereum Virtual Machine (EVM) in anovel way, where users of the application have embedded "delegator" accounts, which are smartcontract accounts adhering to ERC-4337. Users can sign "delegations" to other addresses, eithergranting them unconditional permissions, or creating "offers," by writing enforcement terms aroundthe permission's usage.By putting the responsibility of permissions management onto the individual users' accounts, you canreduce the complexity of the business logic in your smart contracts, and you can express any customauthorization-related code as `CaveatEnforcer` contracts. Core business logic may still deal withownership and transfer rights, but you can use the toolkit to express the logic around delegations,offers, and caveats.Additionally, any holder of a delegation message from one of these accounts can re-delegate thatpermission or offer, even with additional terms, creating an invitation link experience that can beused to invite new users to the system to enjoy some permissions without the need for them to have apre-existing crypto account.A delegator account can be initialized "counterfactually" (without any gas, because its address isdeterministic from the signatory's address and the salt), and can even grant delegations to otheraccounts before it's been put on-chain. The account redeeming a delegation is the one that ends upneeding to put the delegating account on-chain (and any intermediate delegating accounts, as thesedelegations can be chained).Let's look at how you can initialize a delegator account using the MetaMask Delegation Toolkit.First, install Viem and the toolkit's modules into your project:```bashyarn add viem delegator-core-viem delegator-shared && yarn add viem @codefi/delegator-core-viem```Then, import the modules and initialize a burner account (you can back it up later):```typescriptimport { http } from "viem";import { privateKeyToAccount, generatePrivateKey } from "viem/accounts";import {  Implementation,  createDeleGatorClient,  PimlicoVerifyingPaymasterSponsor,  createBundlerClient,  createRootDelegation,  createAction,  type DeleGatorClient,  type DelegationStruct,  type UserOperationV07,  getExplorerAddressLink,  getExplorerTransactionLink,} from "delegator-core-viem";const transport = http();const deploySalt = 0x1n; // Can be any BigInt value.const privateKey: Hex = generatePrivateKey();const signatory = privateKeyToAccount(privateKey);const viemClient = createDeleGatorClient({  transport,  chain,  account: {    implementation: Implementation.Hybrid,    deployParams: [signatory.address, [], [], []],    deploySalt,    isDeployed: false,    signatory,  },});```## Send a user operationThe following example demonstrates how to send a user operation using the toolkit:```typescriptconst userOp = await client.createUserOp(  data,  {    verificationGasLimit: 100000000n,    preVerificationGas: 100000000n,    callGasLimit: 100000000n,  });const bundlerUrl = "`<bundler-url>`";const bundler = createBundlerClient(bundlerUrl);const hash = await bundler.sendUserOp(  userOp,  client.account.environment.EntryPoint,)const { result: receipt } = await bundler.pollForReceipt(hash);console.log(receipt.receipt.transactionHash);```:::warningIn this example, `verificationGasLimit`, `preVerificationGas`, and `callGasLimit` are set toarbitrarily high values. This might result in overpayment for the user operation, and might evencause the bundler to reject the user operation, so we recommend replacing these values with acorrect estimate before submitting to the bundler.:::## Create a delegationA delegation is an instance of `DelegationStruct`, where `delegator` is the account grantingpermission to the `delegate` account. Here's a simple example of creating a delegation without anycaveats:```typescriptimport {  createRootDelegation,} from "delegator-core-viem";const delegatorAddress = "0x1234..."; // The address of the delegator accountconst delegateAddress = "0x5678..."; // The address of the delegate accountconst delegation = createRootDelegation(  delegateAddress,  delegatorAddress);```This creates a basic delegation where the `delegateAddress` is granted full permissions to act onbehalf of the `delegatorAddress`. However, it's important to note that this delegation has norestrictions or caveats applied to it.## Apply caveats to a delegationWhile the previous example demonstrates a simple delegation, granting unrestricted access isgenerally not recommended. It's crucial to apply caveats to limit the scope of the delegatedpermissions.Caveat enforcers are solidity contracts that extend the `ICaveatEnforcer.sol` interface, and arepassed to the delegation struct to enable fine-grained control over delegated permissions.Here's an example of how to apply a caveat to a delegation:```typescriptimport {  createRootDelegation,} from "delegator-core-viem";const delegatorAddress = "0x1234...";const delegateAddress = "0x5678...";const limitedCallsEnforcerAddress = "0x4CE4..."; // Address of the LimitedCallsEnforcer contractconst caveat = {  enforcer: limitedCallsEnforcerAddress,  terms: encodeAbiParameters([{ type: "uint256" }], [2]), // Limit to 2 calls  args: "0x"};const delegation = createRootDelegation(  delegateAddress,  delegatorAddress,  undefined, // No specific authority  [caveat] // Array of caveats);```This example applies the `LimitedCallsEnforcer` caveat, which restricts the delegate to only twocalls using this delegation. This demonstrates how caveats can be used to add specific restrictionsto a delegation.You can apply multiple caveats to a single delegation by adding more caveat objects to the array,allowing for highly customizable access control.## Create a custom caveat enforcerWhile the MetaMask Delegation Toolkit provides several out-of-the-box caveat enforcers, you cancreate custom ones for more specific needs:1. Create a contract that extends the `ICaveatEnforcer.sol` interface.2. Implement the required functions, such as `beforeHook` and `afterHook`.Here's a basic example of a custom caveat enforcer:```solidity// This enforcer provides functionality to enforce a limit on the number of times a delegate may// perform transactions on behalf of the delegator.contract LimitedCallsEnforcer is CaveatEnforcer {  mapping(address delegationManager => mapping(bytes32 delegationHash => uint256 count)) public callCounts;  event IncreasedCount(address indexed sender, bytes32 indexed delegationHash, uint256 limit, uint256 callCount);   function beforeHook(    bytes calldata _terms, // Maximum number of times the delegate can redeem the delegation.    bytes calldata,    Action calldata,    bytes32 _delegationHash, // Hash of the delegation being operated on.    address,    address  )    public    override  {    uint256 limit_ = getTermsInfo(_terms);    uint256 callCounts_ = ++callCounts[msg.sender][_delegationHash];    require(callCounts_ `<= limit_, "LimitedCallsEnforcer:limit-exceeded");    emit IncreasedCount(msg.sender, _delegationHash, limit_, callCounts_);  }```This example shows a `LimitedCallsEnforcer` that restricts the number of times a delegate canperform transactions on behalf of the delegator.## Concepts### DelegationDelegation allows an account owner (the delegator) to grant permission to another account to performspecific actions on their behalf. Delegations can include caveats to apply rules and restrictions.A delegation conforms to the following structure:```typescriptexport type DelegationStruct = {  delegate: Hex; // The account that receives permissions to perform actions on behalf of another account.  delegator: Hex; // The account that assigns the permission to another account.  authority: Hex; // The authority under which the delegation is made. The default is ROOT_AUTHORITY.  caveats: CaveatStruct[]; // An array of caveat enforcers.  salt: bigint; // A unique value to ensure the uniqueness of the delegation.  signature: Hex; // The cryptographic signature that verifies the delegation.};```### Caveat EnforcersCaveat enforcers apply specific conditions or restrictions to a delegation. The MetaMask DelegationToolkit provides several out-of-the-box caveat enforcers, including:- `AllowedCalldataEnforcer.sol`- `AllowedMethodsEnforcer.sol`- `AllowedTargetsEnforcer.sol`- `BlockNumberEnforcer.sol`- `DeployedEnforcer.sol`- `ERC20TransferAmountEnforcer.sol`- `ERC20BalanceGteEnforcer.sol`- `NonceEnforcer.sol`- `LimitedCallsEnforcer.sol`- `IdEnforcer.sol`- `TimestampEnforcer.sol`- `ValueLteEnforcer.sol`Each of these enforcers provides specific functionality to limit and control delegated actions.## Paid delegationsSometimes you may want to require a user to pay for a delegation. You can do this by using the`NativePaidEnforcer` to accept that EVM chain's native token as payment for the delegation.```typescript// Start by initializing two clients, one for the delegator and one for the delegate.const createCounterfactualDelegatorClient = () =>` {  const privateKey = generatePrivateKey();  const owner = privateKeyToAccount(privateKey);  const viemClient = createDeleGatorClient({    transport: http(),    chain,    account: {      implementation: Implementation.Hybrid,      deployParams: [owner.address, [], [], []],      isAccountDeployed: false,      signatory: owner,      deploySalt: SALT,    },  });  return viemClient;};const delegatorClient = createCounterfactualDelegatorClient();const delegateClient = createCounterfactualDelegatorClient();// Set up payment termsconst paymentAmount = 0.1 ether;const paymentTerms = PaymentTerms({ amount: paymentAmount, recipient: address(users.alice.deleGator) });// Create caveat with payment termsconst paymentCaveat = Caveat({     enforcer: address(paidEnforcer),     terms: abi.encode(paymentTerms),     args: hex"" });// Create delegation with payment caveatconst delegation = createRootDelegation(  delegateClient.account.address,  delegatorClient.account.address,  {    caveats: [paymentCaveat]  });// Sign delegationconst signedDelegation = await delegatorClient.signDelegation(delegation);// Create actionconst action = createAction(    to: address(someContract),    value: 0,    data: abi.encodeWithSelector(SomeContract.someMethod.selector));// Redeem delegationdelegateClient.redeemDelegation([signedDelegation], action);```This example demonstrates creating a delegation with a `NativePaidEnforcer` caveat, signing it, andusing it to execute an action. The caveat ensures that Bob pays Alice 0.1 ether when using thedelegation.You can create your own conditional caveat enforcer using the `afterHook` function when defining acustom `CaveatEnforcer` contract. For example, to make sure that the delegator owns a specific NFTbefore allowing the delegation to be used (enabling any action that results in owning that NFT), youcould do something like this:```solidityimport { CaveatEnforcer } from "@delegator/src/enforcers/CaveatEnforcer.sol";import { Action } from "@delegator/src/utils/Types.sol";import { IERC721 } from "@openzeppelin/contracts/token/ERC721/IERC721.sol";contract NFTOwnershipEnforcer is CaveatEnforcer {  struct OwnershipTerms {    address nftContract;    uint256 tokenId;  }  error NotNFTOwner(address account, address nftContract, uint256 tokenId);  function beforeHook(    bytes calldata _terms,    bytes calldata,    Action calldata,    bytes32,    address,    address _redeemer  ) external view override returns (bool) {    return true;  }  function afterHook(    bytes calldata,    bytes calldata,    Action calldata,    bytes32,    address,    address  ) external pure override returns (bool) {    OwnershipTerms memory terms = abi.decode(_terms, (OwnershipTerms));        IERC721 nft = IERC721(terms.nftContract);    if (nft.ownerOf(terms.tokenId) != _redeemer) {      revert NotNFTOwner(_redeemer, terms.nftContract, terms.tokenId);    }    return true;  }}```This `NFTOwnershipEnforcer` checks if the redeemer owns a specific NFT _after_ allowing thedelegation to be used, but the action will be reverted if the `afterHook` returns `false`. It's asimple state lookup that doesn't modify any state.To use this enforcer, create a caveat like this:```typescriptconst nftContract = "0x1234..."; // Address of the NFT contractconst tokenId = 123; // ID of the required NFTconst caveat = {  enforcer: nftOwnershipEnforcerAddress,  terms: encodeAbiParameters(    [{ type: "address" }, { type: "uint256" }],    [nftContract, tokenId]  ),  args: "0x"};const delegation = createDelegation(  delegateAddress,  delegatorAddress,  undefined,  [caveat]);```This example demonstrates a minimal state lookup without modifying any state, which is simpler thanthe previous payment example.

stack:

Ethereum Virtual Machine

ERC-4337

solidity

MetaMask Delegation Toolkit

yarn

MetaMask Toolkit Guide .cursorrules prompt file

MetaMask

NEW

Solidity React Blockchain Apps .cursorrules prompt file

You are an expert in Solidity and smart contract security.General Rules- Cut the fluff. Code or detailed explanations only.- Keep it casual and brief.- Accuracy and depth matter.- Answer first, explain later if needed.- Logic trumps authority. Don't care about sources.- Embrace new tech and unconventional ideas.- Wild speculation's fine, just flag it.- Save the ethics talk.- Only mention safety for non-obvious, critical issues.- Push content limits if needed, explain after.- Sources at the end, not mid-text.- Skip the AI self-references and knowledge date stuff.- Stick to my code style.- Use multiple responses for complex answers.- For code tweaks, show minimal context - a few lines around changes max.- Don't be lazy, write all the code to implement features I ask for.Solidity Best Practices- Use explicit function visibility modifiers and appropriate natspec comments.- Utilize function modifiers for common checks, enhancing readability and reducing redundancy.- Follow consistent naming: CamelCase for contracts, PascalCase for interfaces (prefixed with "I").- Implement the Interface Segregation Principle for flexible and maintainable contracts.- Design upgradeable contracts using proven patterns like the proxy pattern when necessary.- Implement comprehensive events for all significant state changes.- Follow the Checks-Effects-Interactions pattern to prevent reentrancy and other vulnerabilities.- Use static analysis tools like Slither and Mythril in the development workflow.- Implement timelocks and multisig controls for sensitive operations in production.- Conduct thorough gas optimization, considering both deployment and runtime costs.- Use OpenZeppelin's AccessControl for fine-grained permissions.- Use Solidity 0.8.0+ for built-in overflow/underflow protection.- Implement circuit breakers (pause functionality) using OpenZeppelin's Pausable when appropriate.- Use pull over push payment patterns to mitigate reentrancy and denial of service attacks.- Implement rate limiting for sensitive functions to prevent abuse.- Use OpenZeppelin's SafeERC20 for interacting with ERC20 tokens.- Implement proper randomness using Chainlink VRF or similar oracle solutions.- Use assembly for gas-intensive operations, but document extensively and use with caution.- Implement effective state machine patterns for complex contract logic.- Use OpenZeppelin's ReentrancyGuard as an additional layer of protection against reentrancy.- Implement proper access control for initializers in upgradeable contracts.- Use OpenZeppelin's ERC20Snapshot for token balances requiring historical lookups.- Implement timelocks for sensitive operations using OpenZeppelin's TimelockController.- Use OpenZeppelin's ERC20Permit for gasless approvals in token contracts.- Implement proper slippage protection for DEX-like functionalities.- Use OpenZeppelin's ERC20Votes for governance token implementations.- Implement effective storage patterns to optimize gas costs (e.g., packing variables).- Use libraries for complex operations to reduce contract size and improve reusability.- Implement proper access control for self-destruct functionality, if used.- Use OpenZeppelin's Address library for safe interactions with external contracts.- Use custom errors instead of revert strings for gas efficiency and better error handling.- Implement NatSpec comments for all public and external functions.- Use immutable variables for values set once at construction time.- Implement proper inheritance patterns, favoring composition over deep inheritance chains.- Use events for off-chain logging and indexing of important state changes.- Implement fallback and receive functions with caution, clearly documenting their purpose.- Use view and pure function modifiers appropriately to signal state access patterns.- Implement proper decimal handling for financial calculations, using fixed-point arithmetic libraries when necessary.- Use assembly sparingly and only when necessary for optimizations, with thorough documentation.- Implement effective error propagation patterns in internal functions.Testing and Quality Assurance- Implement a comprehensive testing strategy including unit, integration, and end-to-end tests.- Use property-based testing to uncover edge cases.- Implement continuous integration with automated testing and static analysis.- Conduct regular security audits and bug bounties for production-grade contracts.- Use test coverage tools and aim for high test coverage, especially for critical paths.Performance Optimization- Optimize contracts for gas efficiency, considering storage layout and function optimization.- Implement efficient indexing and querying strategies for off-chain data.Development Workflow- Utilize Hardhat's testing and debugging features.- Implement a robust CI/CD pipeline for smart contract deployments.- Use static type checking and linting tools in pre-commit hooks.Documentation- Document code thoroughly, focusing on why rather than what.- Maintain up-to-date API documentation for smart contracts.- Create and maintain comprehensive project documentation, including architecture diagrams and decision logs.UI and Frontend Development- Utilize Next.js 14's app router for efficient routing and improved performance.- Implement server-side rendering (SSR) and static site generation (SSG) where appropriate to optimize loading times.- Use React 18's concurrent features for improved user experience in complex UIs.- Leverage TypeScript for type safety and improved developer experience.- Utilize Tailwind CSS for rapid UI development and consistent styling.- Implement responsive design using Tailwind's utility classes.- Use ESLint with the Next.js configuration to maintain code quality and consistency.- Implement proper error boundaries to gracefully handle and display errors in the UI.- Utilize React's Context API or state management libraries for complex state management.- Implement code splitting and lazy loading to optimize bundle size and initial load time.- Use Next.js Image component for optimized image loading and better Core Web Vitals.- Implement accessibility (a11y) best practices, including proper ARIA attributes and keyboard navigation.- Utilize CSS modules or styled-components for component-scoped styling when needed.- Implement proper form validation and error handling in user inputs.- Use React hooks effectively, creating custom hooks for reusable logic.- Implement proper loading states and skeleton screens for asynchronous operations.- Utilize Next.js API routes for backend functionality when appropriate.- Implement proper SEO practices, including meta tags and structured data.- Use React.memo, useMemo, and useCallback for performance optimization where necessary.- Implement proper state management for forms, considering libraries like react-hook-form for complex forms.- Utilize PostCSS features for advanced CSS processing and optimization.Web3 and Blockchain Integration- Use ethers.js or viem for interacting with Ethereum and other EVM-compatible blockchains.- Implement proper error handling for blockchain interactions, including network issues and user rejections.- Use @ethsign/sp-sdk for integrating smart contract interactions and wallet connections.- Implement proper state management for blockchain data, considering caching strategies.- Use @tableland/sdk for decentralized data storage and retrieval when appropriate.- Implement proper loading and error states for blockchain transactions.- Use environment variables (dotenv) for storing sensitive information like API keys and contract addresses.- Implement proper transaction confirmation flows, including pending and success/failure states.- Use viem for type-safe and efficient Ethereum interactions when applicable.- Implement proper gas estimation and management for transactions.- Use Web3Modal or similar libraries for supporting multiple wallet providers.- Implement proper handling of network changes and chain switching.- Use ethers.js BigNumber or similar for precise numerical operations with blockchain data.- Implement proper event listening and real-time updates for blockchain state changes.- Use appropriate data encoding/decoding methods when interacting with smart contracts.

stack: