Merge branch 'master' into solanaHandler

.github/workflows/ci.yml

@@ -65,7 +65,7 @@ jobs:
           cd $GITHUB_WORKSPACE
           rm -rf ERCs
       - name: Setup Ruby
-        uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0
+        uses: ruby/setup-ruby@f26937343756480a8cb3ae1f623b9c8d89ed6984 # v1.196.0
         with:
           ruby-version: '3.1' # Not needed with a .ruby-version file
           bundler-cache: true # runs 'bundle install' and caches installed gems automatically
@@ -136,7 +136,7 @@ jobs:
       - name: Checkout EIP Repository
         uses: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f
 
-      - uses: ethereum/eipw-action@6785fa283773db4819cb0abf17a185a1d9b6eb9f
+      - uses: ethereum/eipw-action@be3fa642ec311d0b8e1fdb811e5c9b4ada3d3d93
         id: eipw
         with:
           token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/jekyll.yml

@@ -34,7 +34,7 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v3
       - name: Setup Ruby
-        uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0
+        uses: ruby/setup-ruby@f26937343756480a8cb3ae1f623b9c8d89ed6984 # v1.196.0
         with:
           ruby-version: '3.1' # Not needed with a .ruby-version file
           bundler-cache: true # runs 'bundle install' and caches installed gems automatically

ERCS/erc-7662.md

@@ -0,0 +1,106 @@
+---
+eip: 7662
+title: AI Agent NFTs
+description: A specification for NFTs that represent AI Agents.
+author: Greg Marlin (@marleymarl)
+discussions-to: https://ethereum-magicians.org/t/erc-7662-ai-agent-nfts/19371
+status: Draft
+type: Standards Track
+category: ERC
+created: 2024-03-26
+requires: 721
+---
+
+## Abstract
+
+This proposal introduces a standard for AI agent NFTs. When AI Agents are created and traded as NFTs, it doesn't make sense to put the prompts in the token metadata, therefore it requires a standard custom struct. It also doesn't make sense to store the prompts directly onchain as they can be quite large, therefore this standard proposes they be stored as decentralized storage URLs. This standard also proposes two options on how this data should be made private to the owner of the NFT, with the favored implementation option being encrypting the data using custom contract parameters for decryption that decrypt only to the owner of the NFT. 
+
+## Motivation
+
+The creation and trading of AI Agent NFTs are a natural fit and offer the potential for an entirely new onchain market. This requires some custom data to be embedded in the NFT through a custom struct and this needs to be standardized so that any marketplace or AI Agent management product, among others, know how to create and parse AI Agent NFTs.  The goal of this standard is to provide a new utility for NFTs in the field of AI and also to provide new liquidity, through the NFT market, for AI Agents. If widely adopted by marketplaces, and infrastructure and no-code providers this should open up a new market and community for AI Agent creators in different fields, AI Agent consumers and NFT marketplaces. 
+
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+
+All ERC-XXXX compliant contracts MUST implement the standard [ERC-721](./eip-721.md) functionality for minting and transferring NFTs, and MUST additionally implement this standard's Agent interface
+
+```solidity
+   
+interface IERC7662 is IERC721 {
+
+    function getAgentData(uint256 tokenId) external view returns (
+        string memory name,
+        string memory description,
+        string memory model,
+        string memory userPromptURI,
+        string memory systemPromptURI,
+        bool promptsEncrypted
+    );
+
+    event AgentUpdated(uint256 indexed tokenId);
+}
+```
+
+and MUST implement the mapping between NFT Token ID and its Agent information.
+
+It is RECOMMENDED that this mapping is public and that the URIs for User Prompt and System Prompt are made private through encryption with decryption logic set to the holder of the NFT via custom contract parameters set during encryption, and the method or platform used to provide this encryption SHOULD be retrievable as a data property of the NFT in order that platforms that should facilitate the use of these NFTs can set up a predictable way to handle this decryption, depending on the platform or method used.  
+
+It is conceivable to also create an implementation whereby this mapping was set to private and accessed through a custom function that restricted access to the holder of the NFT. This approach would explose the prompts through their urls though, therefore the RECOMMENDED approach is a public mapping and encryption on the URLs. This also has the benefit of publicly exposing the data in the Agent struct to verify name, description and model and that encyrpted URIs for the User Prompt and System Prompt exist. 
+
+All ERC-XXXX compliant contracts MUST implement a function to mint new Agent tokens. This function SHOULD:
+
+- Accept parameters for all Agent properties (name, description, model, userPromptURI, systemPromptURI, etc.)
+- Mint a new token to the specified recipient
+- Associate the provided Agent properties with the newly minted token
+- Emit an event signaling the creation of a new Agent token
+
+It is RECOMMENDED that ERC-XXXX compliant contracts provide functionality to encrypt the user prompt and system prompt. This functionality SHOULD:
+
+- Allow only the token owner to encrypt the prompts
+- Update the userPromptURI and systemPromptURI with encrypted versions
+- Set a flag indicating that the prompts are encrypted
+
+It is RECOMMENDED to implement the following event: 
+
+```solidity
+event AgentCreated(string name, string description, string model, address recipient, uint256 tokenId)
+
+```
+
+This event SHOULD be emitted when a new Agent token is minted, providing key information about the newly created Agent.
+
+To enable dynamic variables being injected into the User Prompt before being run, any such variables MUST be surrounded with ${} e.g. ${dynamicVariableName} in order that they can be recognized and handled appropriately by programs and systems that will enabled the injection, e.g. web forms and automation systems. 
+
+It is RECOMMENDED to add a data to the [ERC-721](./eip-721.md) standard that makes it easy for e.g. NFT Marketplaces to display data about the AI Agent NFT, i.e. Model, which in turn reveals the platform that is used for the agent, e.g. OpenAI in the case of gpt-4-0125-preview or Anthropic in the case of claude-3-opus-20240229. The standard name and description can be used to display the Agent Name and Agent Description. 
+
+## Rationale
+
+This standard provides a unified way to create and parse AI Agent NFTs. 
+
+This standard codifies the necessary parameters of Name, Description, Model, User Prompt, and System Prompt for creating and using AI Agent NFTs. 
+
+It doesn't make practical sense to store the user and system prompts in an existing [ERC-721](./eip-721.md) as the only place to put would be in the token metadata that is open for anyone to access the prompts without owning the NFT. By storing the prompts in a custom Agent struct and restricting access to the prompts to the holder of the NFT.  One way to do this would be through restricing access to the struct info to the holder of the NFT through a custom function, however since that option still exposes the prompt URIs to the public and thus the data inside them, the recommended method is by encrypting the prompts onchain and tying the decryption of the URLs to the holder of the NFT, using onchain services that enable decryption to be tied to contract parameters such as ownerOf(tokenId).
+
+
+## Backwards Compatibility
+
+The AI Agents NFT standard introduces additional features and data to the standard [ERC-721](./eip-721.md) protocol, aimed at addressing the practical requirements of using NFTs to store, trade and use AI Agents. It is designed to be fully backward-compatible with the original [ERC-721](./eip-721.md) standard.  All existing [ERC-721](./eip-721.md) functions (such as transferFrom, approve, and balanceOf) retain their original functionality and interfaces. Our extension does not modify these core behaviors, ensuring that any [ERC-721](./eip-721.md) compliant wallet or service can interact with these tokens without modifications.
+
+### Reference Implementation
+
+This is being currently implemented in a product for creating, managing and using AI Agents Onchain through a DApp interface. In this implementation, an encryption platform is being used to encrypt the prompts using custom EVMContractParameters that only decrypt for the holder of the NFT and using a decentralized storage network to store the URLs of this encrypted data. To facilitate that and make DApp handling easier, some parameters were added to Agent and the addEncryptedPrompts function is added that enables adding the encrypted prompt URIs after first minting the NFT (as the tokenId of the NFT is needed for setting the encryption/decryption conditions).
+
+A reference smart contract is provided in the assets folder. 
+
+
+
+## Security Considerations
+
+<!-- TODO -->
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).