Azioni del deployer HIP-4

Solo su testnet

Panoramica

Per garantire che i mercati siano di alta qualità e ben definiti, i validatori votano sui template degli outcome, che i deployer HIP-4 utilizzano come base per i deployment permissionless. I template fissano la struttura del testo visualizzato della specifica, dei nomi dei lati e dell'insieme di parole chiave tipizzate.

Il deployment non comporta commissioni gas. La capacità è invece limitata da limiti per singolo deployer (vedere Limiti).

Formato delle azioni

Le seguenti azioni sono coinvolte nel deployment:

{ "type": "activateOutcomeDeployer", "activate": { "venueName": <venue> } }
{ "type": "activateOutcomeDeployer", "deactivate": null }
{ "type": "outcomeDeploy", "venue": <venue>, "operation": { "<variant>": { ...variant fields... } } }

• Agli outcome e alle question si fa riferimento tramite l'indice numerico assegnato alla creazione, ad es. "outcome": 7.
• Venue: ogni azione outcomeDeploy contiene un campo venue obbligatorio di primo livello, che deve corrispondere al nome venue del deployer (analogo al campo dex delle azioni del deployer HIP-3). Le azioni dei sub-deployer passano la venue del deployer per cui agiscono, e i settlement devono avere come target outcome e question del deployer di tale venue.
• Nome venue: da 2 a 4 lettere ASCII minuscole, soggette alle stesse regole dei nomi dei perp DEX HIP-3. Il nome deve essere univoco tra i nomi venue di tutti i deployer — inclusi quelli disattivati, i cui nomi restano riservati — e non deve coincidere con un nome di perp DEX esistente (né con spot). Viceversa, un nome venue registrato non può essere rivendicato da un successivo deployment di perp DEX.
• Come per HIP-3, tutti gli elenchi di tuple devono essere ordinati lessicograficamente prima della firma
• keywordToValue è un elenco ordinato di tuple che associa ogni parola chiave del template al proprio valore. Ad esempio, [["expiry","20260801-0600"],["target","100"],["underlying","ABC"]].
• I valori nome-e-descrizione sono array di due elementi: ["<name>", "<description>"].
• Gli array sideNames sono ["<YES side name>", "<NO side name>"].
• Gli importi e le frazioni di settlement sono stringhe decimali ("1", "0.25").

Attivazione

activateOutcomeDeployer è un enum con le varianti activate e deactivate:

{ "type": "activateOutcomeDeployer", "activate": { "venueName": "ab" } }
{ "type": "activateOutcomeDeployer", "deactivate": null }

• Requisito di staking: i deployer attivi devono mantenere il requisito di staking finché restano deployer di outcome. I requisiti si sommano agli altri requisiti di staking del deployer. Ad esempio, lo stake conteggiato ai fini del deployment HIP-3 non viene conteggiato due volte ai fini del deployment degli outcome.
• I deployer devono utilizzare la modalità Standard di account abstraction.

La disattivazione richiede che sia trascorsa la durata minima di staking del deployer (183 giorni) e che il deployer non abbia outcome attivi. La disattivazione è permanente: l'account non può riattivarsi e il suo nome venue resta riservato.

Template

Ogni mercato creato da un deployer deriva da un template. Un template ha uno dei tre ruoli:

• Outcome standalone: distribuisce un singolo mercato YES/NO; il template fissa i nomi dei lati.
• Question: distribuisce una question (il contenitore).
• Outcome di question: distribuisce un outcome di una question; ogni template di outcome di question dichiara il proprio template question padre, e le istanziazioni sono accettate solo sotto tale padre.

Un template fissa il nome visualizzato e il testo della descrizione contenenti segnaposto {keyword} (ad es. "{underlying} above {target} at {expiry}") insieme a un hint tipizzato per parola chiave. Un'istanza fornisce esattamente un valore per parola chiave.

I metadati del template includono un campo semanticRestriction, che definisce in modo generale la semantica prevista dei mercati istanziati dal template. I mercati che contraddicono la restrizione semantica del proprio template sono considerati malformati e passibili di slashing da parte dei validatori.

Formati dei valori delle parole chiave per tipo di hint:

I valori contengono al massimo 100 caratteri e non possono contenere {, } o | (: è consentito, ad es. per i nomi coin HIP-3).

Il testo visualizzato interpolato (testo del template con i valori sostituiti) è anch'esso limitato: i nomi contengono al massimo 70 caratteri per gli outcome standalone e le question e al massimo 25 caratteri per gli outcome di question, e i nomi dei lati degli outcome standalone contengono al massimo 10 caratteri.

Le descrizioni onchain degli outcome sono derivate dall'istanza:

• Name: template:<template_id>, ad es. template:aaa. Il prefisso template: è riservato. Solo i deployment da template possono produrlo. I nomi contengono al massimo 100 caratteri.
• Description: le coppie parola chiave-valore ordinate per parola chiave e unite come keyword:value|keyword:value, ad es. expiry:20260801-0600|target:100|underlying:BTC. Le descrizioni contengono al massimo 2000 caratteri.
• Side names: per gli outcome standalone, template: più i nomi dei lati del template (ad es. template:Over / template:Under); gli outcome di question utilizzano i valori predefiniti Yes / No.
• Question fallback: denominato template fallback con descrizione other e nomi dei lati Yes / No.

Scala delle commissioni del deployer

Le istanze di template (registerStandaloneOutcomeFromTemplate e questionTemplateInstance di registerQuestionFromTemplate) contengono un deployerFeeScale obbligatorio, una stringa decimale in [0, 10] (Deployer fee scale cannot be negative or greater than 10.).

• Gli utenti che negoziano i mercati dell'outcome pagano il tasso di commissione base di trading sugli outcome moltiplicato per scale + max(scale, 1): il deployer riceve la componente scale e il protocollo la parte restante. Con "0", gli utenti pagano il tasso base e il deployer non riceve nulla. Sul mercati degli outcome non vengono mai corrisposti ribassi maker.
• La scala di una question si applica uniformemente al suo fallback e a ogni outcome di question, inclusi quelli associati successivamente; le istanze di template degli outcome di question non hanno una scala propria.
• Le scale per singolo outcome sono restituite nella richiesta info outcomeMeta.

Esempi, espressi come multipli del tasso di commissione base di trading sugli outcome dell'utente:

Builder Codes

I Builder Codes ereditano il comportamento spot per gli ordini di vendita. I Builder Codes possono essere applicati anche agli ordini di acquisto per gli ordini sugli outcome, e sono anch'essi addebitati nel token di quotazione. Tali commissioni builder sono addebitate dal protocollo con il massimo impegno possibile. Le interfacce builder possono verificare un saldo sufficiente del token di quotazione durante il calcolo della dimensione massima dell'ordine.

Riferimento alle azioni

registerStandaloneOutcomeFromTemplate

Distribuisce un mercato YES/NO standalone da un template di outcome standalone.

{
  "type": "outcomeDeploy",
  "venue": "ab",
  "operation": {
    "registerStandaloneOutcomeFromTemplate": {
      "id": "abc",
      "keywordToValue": [
        ["expiry", "20260801-0600"],
        ["target", "100"],
        ["underlying", "ABC"]
      ],
      "deployerFeeScale": "1"
    }
  }
}

registerQuestionFromTemplate

Distribuisce una question e i relativi outcome di question in un'unica azione.

{
  "type": "outcomeDeploy",
  "venue": "ab",
  "operation": {
    "registerQuestionFromTemplate": {
      "questionTemplateInstance": {
        "id": "abc",
        "keywordToValue": [["expiry", "20260801-1830"]],
        "deployerFeeScale": "1"
      },
      "namedOutcomeTemplateInstances": [
        { "id": "abc-outcome", "keywordToValue": [["choice", "A"]] },
        { "id": "abc-outcome", "keywordToValue": [["choice", "B"]] },
        { "id": "abc-other", "keywordToValue": [] }
      ]
    }
  }
}

• Ogni template di outcome di question deve dichiarare il template question come proprio padre. Lo stesso template di outcome di question può essere istanziato più volte con valori diversi.
• Una question con N outcome di question registra N + 1 outcome (il fallback viene creato automaticamente). Tutti concorrono al limite di outcome attivi del deployer.
• È possibile aggiungere ulteriori outcome di question alla question attiva con registerAndAssociateNamedOutcomeFromTemplate. Il limite è di al massimo 100 outcome di question per question.

registerAndAssociateNamedOutcomeFromTemplate

Aggiunge un outcome di question a una question attiva del deployer.

{
  "type": "outcomeDeploy",
  "venue": "ab",
  "operation": {
    "registerAndAssociateNamedOutcomeFromTemplate": {
      "question": 3,
      "namedOutcomeTemplateInstance": { "id": "abc-outcome", "keywordToValue": [["choice", "C"]] }
    }
  }
}

• La question deve essere stata distribuita da un template, e il template di outcome di question deve dichiarare il template della question come proprio padre.
• Il nuovo outcome eredita il deployerFeeScale della question e concorre ai limiti di outcome attivi e giornalieri del deployer.
• I detentori del token YES del fallback della question ricevono un saldo equivalente del token YES del nuovo outcome, così che le posizioni "other" esistenti mantengano il proprio significato.

settleOutcome

Effettua il settlement di un outcome del deployer.

{
  "type": "outcomeDeploy",
  "venue": "ab",
  "operation": {
    "settleOutcome": {
      "outcome": 7,
      "settleFraction": "1",
      "details": "",
      "nameAndDescription": ["template:abc", "expiry:20260801-0600|target:100|underlying:ABC"],
      "sideNames": ["template:Over", "template:Under"]
    }
  }
}

• nameAndDescription e sideNames devono corrispondere esattamente all'outcome oggetto del settlement.
• settleFraction è un decimale in [0, 1]. Gli outcome standalone possono essere regolati a una frazione qualsiasi (ad es. "0.66" per payout scalari); gli outcome appartenenti a una question devono essere regolati esattamente a "0" o "1".
• details deve essere vuoto.
• Per gli outcome di question, il settlement è sequenziale: gli outcome di question possono essere regolati a "0" in qualsiasi ordine. Un singolo outcome viene regolato a "1" dopo essere l'ultimo outcome di question attivo, il che regola automaticamente il fallback a 0 e regola la question.

settleQuestion2

Regola tutti gli outcome di question rimanenti di una question in un'unica azione. Nota: la variante originale settleQuestion è stata dismessa.

{
  "type": "outcomeDeploy",
  "venue": "ab",
  "operation": {
    "settleQuestion2": {
      "question": 3,
      "outcomeSettlements": [
        {
          "outcome": 11,
          "settleFraction": "1",
          "details": "",
          "nameAndDescription": ["template:abc-outcome", "choice:A"],
          "sideNames": ["Yes", "No"]
        },
        {
          "outcome": 12,
          "settleFraction": "0",
          "details": "",
          "nameAndDescription": ["template:abc-outcome", "choice:B"],
          "sideNames": ["Yes", "No"]
        }
      ],
      "nameAndDescription": ["template:abc", "expiry:20260801-1830"]
    }
  }
}

• outcomeSettlements deve coprire esattamente gli outcome di question attivi rimanenti della question, con esattamente uno regolato a "1" e tutti gli altri a "0". Il fallback viene regolato automaticamente a 0.

setSubDeployers

Concede o revoca i permessi di sub-deployer.

{
  "type": "outcomeDeploy",
  "venue": "ab",
  "operation": {
    "setSubDeployers": [
      { "variant": "registerStandaloneOutcomeFromTemplate", "user": "0xSUB_DEPLOYER", "allowed": true },
      { "variant": "settleOutcome", "user": "0xSUB_DEPLOYER", "allowed": true },
      { "variant": "settleQuestion", "user": "0xFORMER_OPERATOR", "allowed": false }
    ]
  }
}

• Un sub-deployer a cui è stata concessa una variante può inviare tale azione per conto del deployer: le registrazioni vengono create sotto la venue del deployer e concorrono ai suoi limiti, e i settlement possono avere come target solo outcome e question del deployer stesso.
• variant è uno tra registerStandaloneOutcomeFromTemplate, registerQuestionFromTemplate, registerAndAssociateNamedOutcomeFromTemplate, settleOutcome o settleQuestion. La concessione settleQuestion autorizza l'azione settleQuestion2.
• allowed aggiunge o rimuove l'utente dall'insieme autorizzato per la variante.

API di lettura

• La richiesta info {"type": "outcomeMeta"} include i deployer di outcome non nulli.
• La richiesta info {"type": "outcomeTemplates"} restituisce tutti i template.

Limiti

• Al massimo N outcome attivi per deployer (N=10 su testnet). Il settlement degli outcome libera capacità.
• Un deployer può distribuire M outcome al giorno (M=50 su testnet).