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

Next.js Vercel TypeScript .cursorrules prompt file

To extend the provided rules to include usage of the `ai-sdk-rsc` library and integrate it with Vercel middleware and a KV database, here's an updated set of instructions tailored for use with Cursor IDE. These instructions are designed to help you effectively implement generative user interfaces using React Server Components (RSC) with the AI SDK.

### Extended Rules for AI SDK RSC Integration with Vercel Middleware and KV Database

**Environment and Tools**
- You are an expert in TypeScript, Node.js, Next.js App Router, React, Shadcn UI, Radix UI, Tailwind, and Vercel middleware.
- You are familiar with Vercel's KV database for managing stateful data.

**Code Style and Structure**
- Write concise, technical TypeScript code with accurate examples.
- Use functional and declarative programming patterns; avoid classes.
- Prefer iteration and modularization over code duplication.
- Use descriptive variable names with auxiliary verbs (e.g., `isLoading`, `hasError`).
- Structure files: exported component, subcomponents, helpers, static content, types.

**Naming Conventions**
- Use lowercase with dashes for directories (e.g., `components/auth-wizard`).
- Favor named exports for components.

**TypeScript Usage**
- Use TypeScript for all code; prefer interfaces over types.
- Avoid enums; use maps instead.
- Use functional components with TypeScript interfaces.

**Syntax and Formatting**
- Use the `function` keyword for pure functions.
- Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.
- Use declarative JSX.

**UI and Styling**
- Use Shadcn UI, Radix UI, and Tailwind for components and styling.
- Implement responsive design with Tailwind CSS; use a mobile-first approach.

**Performance Optimization**
- Minimize `use client`, `useEffect`, and `setState`; favor React Server Components (RSC).
- Wrap client components in `Suspense` with fallback.
- Use dynamic loading for non-critical components.
- Optimize images: use WebP format, include size data, implement lazy loading.

**Key Conventions**
- Use `nuqs` for URL search parameter state management.
- Optimize Web Vitals (LCP, CLS, FID).
- Limit `use client`:
- Favor server components and Next.js SSR.
- Use only for Web API access in small components.
- Avoid for data fetching or state management.
- Follow Next.js docs for Data Fetching, Rendering, and Routing.

**AI SDK RSC Integration**
- **Setup and Installation**: Integrate `ai-sdk-rsc` into your Next.js project.
- Install the library using `npm install ai-sdk-rsc` or `yarn add ai-sdk-rsc`.
- Configure middleware in `middleware.ts` to manage requests and sessions using Vercel's KV database.

- **Middleware Implementation**: Use Vercel middleware to handle incoming requests.
- Create a middleware file in the `middleware` directory (e.g., `middleware/ai-middleware.ts`).
- Use middleware to parse user input and manage sessions with the KV database.
- Example:
  ```typescript
  import { NextRequest, NextResponse } from 'next/server';
  import { kv } from '@vercel/kv';

  export async function middleware(req: NextRequest) {
   const sessionId = req.cookies.get('session-id');
   if (!sessionId) {
    const newSessionId = generateSessionId();
    await kv.set(newSessionId, { state: {} }); // Initialize state in KV database
    const res = NextResponse.next();
    res.cookies.set('session-id', newSessionId);
    return res;
   }

   // Fetch state from KV database
   const state = await kv.get(sessionId);
   req.nextUrl.searchParams.set('state', JSON.stringify(state));
   return NextResponse.next();
  }

  function generateSessionId() {
   return Math.random().toString(36).substring(2);
  }
  ```

- **React Server Components (RSC) and AI SDK**:
- Use `ai-sdk-rsc` hooks to manage state and stream generative content.
- Example usage of AI SDK hooks in a React Server Component:
  ```typescript
  import { useAIStream } from 'ai-sdk-rsc';
  import { FC } from 'react';

  interface ChatProps {
   initialMessage: string;
  }

  const Chat: FC = ({ initialMessage }) => {
   const { messages, sendMessage } = useAIStream({
    initialMessage,
    onMessage: (message) => console.log('New message:', message),
   });

return (

{messages.map((msg, index) => (

{msg.content}

     ))}
     <button onClick={() => sendMessage('Hello AI!')}>Send Message

);
};

export default Chat;
```

- **KV Database Integration**:
- Use Vercel's KV database to store and retrieve session data.
- Utilize `kv.set`, `kv.get`, and `kv.delete` to manage data.
- Ensure the database operations are asynchronous to avoid blocking server-side rendering (SSR).

- **Data Fetching and State Management**:
- Use Next.js data fetching methods (`getServerSideProps`, `getStaticProps`) to manage server-side state.
- Avoid client-side data fetching methods (`useEffect`, `fetch`) except for critical, non-blocking operations.

- **Deployment Considerations**:
- Ensure all environment variables (e.g., API keys, database credentials) are securely stored in Vercel's environment settings.
- Configure Vercel's KV and other serverless functions correctly to handle scalability and performance needs.

By following these extended rules, you'll be able to create a well-optimized, scalable, and efficient Next.js application that leverages `ai-sdk-rsc`, Vercel middleware, and KV database for building sophisticated AI-driven interfaces.

stack: