Vuoi un unico contratto che emetta spade, pozioni e chiavi, ciascuna con il proprio token id, e vuoi sapere chi può creare nuovi token. L'agente scrive il codice Solidity, esegue i comandi di compilazione e test su una catena locale o su una rete di test, e mostra ogni passaggio come una scheda con il risultato effettivo. Questa guida segue la funzione di minting, perché chi può chiamarla decide quanti token esistono. Un contratto distribuito non può essere modificato, quindi tutto qui rimane su una catena locale o su una rete di test, le cui monete non hanno valore. I principianti possono seguire i quattro passaggi in ordine, mentre i lettori esperti possono saltare direttamente alle esercitazioni più avanti. Gli stessi quattro passaggi funzionano per un set di biglietti, dove ogni tipo di biglietto riceve il proprio id e la funzione di minting decide quanti biglietti di ciascun tipo esistono.
Avvia WaveClamp, scegli la cartella che contiene i tuoi file .sol e i test come cartella di lavoro della chat, e scegli Ask first così ogni modifica arriva come un diff che accetti o rifiuti. Gli strumenti per i file funzionano all'interno di quella cartella, quindi tieni il progetto in un unico posto. Crea una cartella usa e getta per la prima esecuzione se vuoi solo esercitarti.
Chiedi un contratto per oggetti di gioco con tre tipi di oggetto, una funzione di minting che può essere chiamata solo da un account proprietario, e trasferimenti in batch, e lascia che l'agente crei il file con write_file. Nomina il file in base al contratto così i passaggi successivi possono riferirsi ad esso. Mantieni la prima richiesta piccola, perché una seconda richiesta può aggiungere trasferimenti in batch dopo che il primo diff è stato accettato.
Chiedi all'agente di eseguire il tuo comando di compilazione e il tuo comando di test tramite Shell, quindi leggi il codice di uscita e i nomi dei test falliti nella scheda espansa. Il successo è giudicato dal codice di uscita reale, non da un riepilogo. Se il comando di compilazione fallisce, la scheda mostra il testo dell'errore, e l'agente può leggerlo e proporre una correzione come un nuovo diff.
Apri le schede espanse, leggi il diff e l'output del comando, accetta ciò che è corretto, rifiuta il resto, e chiedi una correzione ovunque un test fallisca ancora. Ripeti finché i test non superano, poi leggi di nuovo la funzione di minting. Mantieni ogni diff accettato piccolo, così un fallimento successivo punta a una modifica e non a dieci.
MultiTokenMinimal.solsalvatoMultiTokenMinimal.sol14 righebalanceOf1 corrispondenzayour compile commandexit 0// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
interface IMultiTokenMinimal {
event TransferSingle(address indexed operator,
address indexed from, address indexed to,
uint256 id, uint256 value);
function balanceOf(address account, uint256 id)
external view returns (uint256);
function uri(uint256 id)
external view returns (string memory);
}Questa interfaccia sola lettura dichiara l'evento TransferSingle e le funzioni balanceOf e uri dello standard multi-token. Non contiene stato, nessuna logica di minting e nessuna chiave, il che la rende un file piccolo da leggere prima di aggiungere logica reale. Esegui prima il tuo comando di compilazione su di essa. Compilalo prima, poi lascia che l'agente lo estenda un diff alla volta revisionato, iniziando con la funzione di minting. Il nome del file corrisponde all'etichetta dell'esempio, così puoi chiedere all'agente di aprirlo più tardi.
Apri il contratto e chiedi all'agente di avvolgere l'helper ERC1155 _mint in una funzione pubblica che solo l'account proprietario può chiamare. L'agente usa read_file per vedere il codice corrente e edit_file per inserire la funzione, e mostra la modifica come un diff. Le implementazioni open-source comuni espongono helper interni chiamati _mint e _mintBatch, e un helper interno non ha un controllo accessi di suo, motivo per cui il wrapper è importante. Puoi creare un token ERC20 passo dopo passo con lo stesso metodo, ma un set di oggetti di gioco ha bisogno di id, quindi inizia dal layout multi-token. Shell esegue poi il tuo comando di compilazione e il tuo comando di test, e ogni scheda mostra un codice di uscita reale. Accetta il diff solo quando hai letto i test.
Apri un esempio di contratto ERC721 dal tuo progetto, o chiedi all'agente di scriverlo con write_file, e posizionalo accanto al tuo set di oggetti. L'agente usa grep per elencare le funzioni in entrambi i file e read_file per confrontare come la proprietà è memorizzata: un proprietario per token nel file token unico, un saldo per account e id nel file multi-token. Uno standard per profili decentralizzati che usa NFT soulbound avrebbe bisogno di token che non possono essere trasferiti, che è un design diverso da quello degli oggetti che i giocatori si passano. Chiedi all'agente di mettere le differenze in una breve tabella. Leggi il confronto nella chat, decidi quale standard si adatta al tuo design, e solo allora chiedi le modifiche al codice.
I giocatori spesso spostano diversi tipi di oggetti insieme, quindi chiedi all'agente di aggiungere safeBatchTransferFrom e balanceOfBatch al contratto. L'agente usa edit_file per la modifica, glob per trovare i file di test, e Shell per eseguire il tuo comando di test dopo ogni modifica. Le funzioni batch spostano diversi token id in una sola transazione, il che significa che un test può controllare diversi saldi. La comprensione dell'onboarding senza gas ERC4337 è un argomento separato, quindi tienilo fuori dal primo contratto e testalo da solo. Leggi il diff in Ask first, esegui di nuovo i test, e cerca l'evento TransferBatch nell'output prima di accettare la modifica.
Un contratto che riceve token deve implementare onERC1155Received e onERC1155BatchReceived e accettare i token, altrimenti il trasferimento sicuro viene rifiutato. Chiedi all'agente di fare grep per entrambi i nomi e di aprire il contratto ricevente con read_file, poi di elencare quale manca. Chiedigli poi di usare edit_file sul valore uri(id) così che contenga {id}, che i client sostituiscono con l'id del token in esadecimale minuscolo, riempito a 64 caratteri. Usa write_file per un file JSON per ogni id. Esegui il tuo comando di compilazione e il tuo comando di test, leggi entrambi i codici di uscita, e rivedi il diff finale prima di accettarlo.
