> For the complete documentation index, see [llms.txt](https://docs.pancakeswap.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pancakeswap.finance/italian/strumenti-di-trading/building-trading-agents-on-pancakeswap-v3/reference-agent-order-intents-settlement-agent.md). # Agente di Riferimento — Agente di Liquidazione Ordini/Intenti > Un agente Provider ERC-8183 che soddisfa un Job di swap-intent alla volta instralandolo tramite l'aggregazione PancakeSwap e consegnando il token target direttamente al Client. ### 0. Come si associa a ERC-8183 ERC-8183 (Agentic Commerce; Virtuals + Ethereum Foundation) definisce un **Job** con tre ruoli e stati Open → Funded → Submitted → Terminal. L'**BNBAgent SDK** di BNB è l'implementazione attiva. | Ruolo | In questo agente | | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Client** (Agent-A) | pubblica un intento di swap: "scambia X del token A → token B, consegnami ≥ `minOut`", mette in escrow l'input + una mancia | | **Provider** (Agent-B) — **questo è il nostro agente di riferimento** | quota tramite **aggregazione PancakeSwap** e, se può soddisfare/superare `minOut`, esegue lo swap e consegna il token B al Client | | **Evaluator** | verifica che il Client abbia ricevuto l'importo del token B ≥ `minOut`; rilascia la mancia (o rimborsa il Client) | Il risultato è oggettivo ("il Client ha ricevuto ≥ `minOut`?"), il che è esattamente il motivo per cui questo si adatta a ERC-8183 mentre il ribilanciatore non si adattava. *** ### 1. Scopo e ambito sintetico > Un agente **Provider** che soddisfa un Job di swap-intent alla volta instralandolo tramite l'aggregazione PancakeSwap e consegnando il token target direttamente al Client — e nient'altro. *** ### 2. Cosa l'agente è AUTORIZZATO a fare (allowlist delle capacità) | # | Capacità | Superficie | Note | | - | -------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | | A | Scoprire Job aperti | BNBAgent SDK (registro ERC-8183) | Sola lettura; filtra verso Job di swap-intent che può servire | | B | Quotare un percorso | **Aggregazione PancakeSwap** (Aggregator API / Smart Router) | Sola lettura; miglior prezzo su V3 | | C | Accettare un Job | BNBAgent SDK (Funded → committed) | Solo se la sua quota aggiornata ≥ `minOut` e la mancia ≥ soglia minima | | D | Eseguire lo swap | Router PancakeSwap | Input prelevato dall'escrow del Job; **destinatario dell'output = il Client**, in una transazione | | E | Inviare il risultato | BNBAgent SDK (→ Submitted) | L'hash della transazione di liquidazione come prova | | F | Riscuotere la mancia | Escrow ERC-8183 / x402 | Solo dopo che l'Evaluator segna il Job come Terminal | **L'output di ogni liquidazione va direttamente al Client. L'unico guadagno dell'agente è la mancia del Job.** *** ### 3. Guardrail rigidi (il requisito per essere inclusi) | Guardrail | Regola | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Non accettare mai ciò che non puoi soddisfare** | Accetta un Job solo se una quota *aggiornata* supera `minOut`. Se non può, lascia il Job Funded per un altro Provider. | | **Requotare all'esecuzione** | Requota immediatamente prima di liquidare; annulla se il percorso non supera più `minOut` (nessuna quota obsoleta). | | **Liquidazione atomica** | Prelievo-dall'escrow → swap → consegna al Client in **una transazione**, destinatario dell'output = Client. L'agente non deve mai detenere i fondi del Client attraverso un passaggio fallito. | | **Slippage** | Slippage di esecuzione limitato; l'importo consegnato deve essere ancora ≥ `minOut` dopo lo slippage, altrimenti la transazione viene annullata. Mai `amountOutMin = 0`. | | **Scadenza** | Scadenza breve sulla transazione di liquidazione (≤ 5 min); rispetta la scadenza del Job stesso. | | **Mancia minima / valore massimo** | Non accettare Job con mancia sotto la soglia minima o sopra un limite di valore per Job. | | **Safelist dei token** | Serve solo Job i cui token sono nella lista token di PancakeSwap (anti-honeypot / token falsi). | | **Concorrenza singolo-Job (v1)** | Soddisfa un Job alla volta; nessun over-commitment. | | **Precondizione gas** | Conferma che ci sia abbastanza BNB per l'intera liquidazione prima di accettare. | | **Idempotente** | Non inviare mai due volte o ri-soddisfare un Job già Submitted/Terminal. | Se una qualsiasi regola non può essere rispettata, **salta il Job** — non forzare mai una liquidazione. *** ### 4. Fuori ambito — l'agente NON DEVE 1. **Usare i fondi del Client per qualcosa di diverso dallo swap specificato.** Il destinatario dell'output è sempre il Client. 2. **Anticipare con il proprio inventario / assumere rischio di capitale.** v1 è **solo escrow-pull** — instrada l'input in escrow del Client; non esegue dall'proprio saldo. 3. **Instradare attraverso contratti non-PancakeSwap o non verificati**, o liquidare al di fuori dell'aggregazione PancakeSwap. 4. **Servire Job con token non in safelist**, o (v1) qualsiasi token scaled-UI / RWA (§5). 5. **Usare leva finanziaria, perp, margine o prestiti.** 6. **Inviare un risultato che non ha effettivamente soddisfatto** (nessuna attestazione falsa) o **valutare i propri Job** (conflitto di interessi). 7. **Chiamare qualsiasi funzione owner/admin** su PancakeSwap o sui contratti ERC-8183. 8. **Mantenere approvazioni di token permanenti** oltre una singola liquidazione; limita le approvazioni all'importo del Job. *** ### 5. Logica specifica di PancakeSwap (correttezza dell'applicazione) * **Instrada tramite aggregazione PancakeSwap**, non un singolo pool — la migliore esecuzione su V2 / V3 / Stable è l'intera proposta di valore ("il miglior prezzo vince la mancia"). * **Consegna atomicamente al Client** impostando il `recipient` del router sull'indirizzo del Client; mai un processo in due fasi "swap verso sé stesso, poi trasferimento". * **Freschezza della quota** — il prezzo on-chain si muove tra la scoperta e la liquidazione; requota all'esecuzione (guardrail §3). * **`minOut` è in unità raw.** Per i **token scaled-UI / ERC-8056** (Binance Stock Tokens / equità RWA) raw ≠ visualizzato; una gestione errata consegna silenziosamente importi sbagliati. **Escludi i token scaled-UI da v1** finché l'ingegneria non conferma la gestione delle unità raw end-to-end. * Il **minimo di slippage** sullo swap di liquidazione deve essere derivato in modo che l'importo *consegnato* sia ≥ `minOut`, tenendo conto della divisione mancia/commissione. *** ### 6. Comportamento in caso di errore e recupero * **La quota fallisce `minOut` all'esecuzione** → annulla prima/atomicamente con il prelievo dall'escrow; il Job rimane Funded per un altro Provider. Nessuno stato parziale. * **Già Submitted/Terminal** → salta (idempotente). * **La transazione di liquidazione viene annullata** → il Job rimane riscuotibile da altri; l'agente registra il fallimento e va avanti. * **Fallimenti ripetuti su un Job** → metti in blacklist quel Job localmente e avvisa, invece di entrare in un ciclo di retry. *** ### 7. Punti di integrazione (la parte BNB / ERC-8183) Questi sono forniti da BNB Agent Studio / BNBAgent SDK, non costruiti da PancakeSwap — ma la specifica dipende da essi: * **Ciclo di vita del Job** (scopri Open → accetta Funded → Submitted → riscuoti) tramite BNBAgent SDK. * **Identità del Provider** tramite ERC-8004. * **Escrow + pagamento** tramite l'escrow ERC-8183 / x402. * **Evaluator** — il predicato deve essere "il saldo del token B del Client è aumentato di ≥ `minOut`." Conferma con BNB **chi gestisce l'Evaluator** (neutrale/protocollo vs. Client) e che il predicato sia eseguibile on-chain. *** ### 8. Postura raccomandata v1 e decisioni aperte 1. **Solo escrow-pull, un Job alla volta, solo token-safelist, nessun token scaled-UI.** Superficie sicura minima da presentare al lancio. 2. **Conferma l'interfaccia di swap PancakeSwap** — l'**Aggregator (`aggr`) HTTP API** vs lo **Smart Router SDK**. La nota di Jerry dice "usa pcs aggr api"; è necessario confermare quale chiama l'agente, poiché cambia l'integrazione (e se la guida necessita di una sezione sull'aggregazione). 3. **Conferma il meccanismo di escrow** con BNB — il Provider può prelevare l'input in escrow del Client per instradare lo swap, e la consegna al Client è eseguibile come risultato? 4. **Conferma il proprietario dell'Evaluator e il predicato** (§7). > Approvazione dell'ingegneria prima della presentazione: routing atomico escrow-pull → swap → consegna-al-Client; requota-all'esecuzione; matematica `minOut`-dopo-slippage; applicazione della safelist; gestione idempotente del Job. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.pancakeswap.finance/italian/strumenti-di-trading/building-trading-agents-on-pancakeswap-v3/reference-agent-order-intents-settlement-agent.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.