HIP-4-Deployer-Aktionen

Nur im Testnet

Überblick

Um sicherzustellen, dass Märkte von hoher Qualität und klar definiert sind, stimmen Validatoren über Outcome-Vorlagen ab, die HIP-4-Deployer als Grundlage für erlaubnisfreie Deployments verwenden. Die Vorlagen legen die Struktur des Anzeigetexts der Spezifikation, die Seitennamen und die Menge der typisierten Schlüsselwörter fest.

Das Deployment verursacht keine Gas-Gebühr. Die Kapazität wird stattdessen durch Limits pro Deployer begrenzt (siehe Limits).

Aktionsformat

Die folgenden Aktionen sind am Deployment beteiligt:

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

• Outcomes und Questions werden über den bei der Erstellung zugewiesenen numerischen Index referenziert, z. B. "outcome": 7.
• Venue: Jede outcomeDeploy-Aktion enthält ein erforderliches venue-Feld auf oberster Ebene, das dem Venue-Namen des Deployers entsprechen muss (ähnlich dem dex-Feld bei HIP-3-Deployer-Aktionen). Sub-Deployer-Aktionen übergeben das Venue des Deployers, für den sie handeln, und Settlements müssen sich auf Outcomes und Questions des Deployers dieses Venue beziehen.
• Venue-Name: 2–4 kleingeschriebene ASCII-Buchstaben, gemäß denselben Regeln wie HIP-3-Perp-DEX-Namen. Der Name muss über die Venue-Namen aller Deployer hinweg eindeutig sein — einschließlich deaktivierter, deren Namen reserviert bleiben — und darf nicht mit einem bestehenden Perp-DEX-Namen übereinstimmen (auch nicht mit spot). Umgekehrt kann ein registrierter Venue-Name nicht durch ein späteres Perp-DEX-Deployment beansprucht werden.
• Wie bei HIP-3 sollten alle Listen von Tupeln vor dem Signieren lexikografisch sortiert werden
• keywordToValue ist eine sortierte Liste von Tupeln, die jedes Vorlagen-Schlüsselwort seinem Wert zuordnet. Beispiel: [["expiry","20260801-0600"],["target","100"],["underlying","ABC"]].
• Name-und-Beschreibung-Werte sind zweielementige Arrays: ["<name>", "<description>"].
• sideNames-Arrays sind ["<YES side name>", "<NO side name>"].
• Beträge und Settlement-Anteile sind Dezimalzeichenketten ("1", "0.25").

Aktivierung

activateOutcomeDeployer ist ein Enum mit den Varianten activate und deactivate:

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

• Staking-Anforderung: Aktive Deployer müssen die Staking-Anforderung aufrechterhalten, solange sie Outcome-Deployer sind. Die Anforderungen addieren sich zu den übrigen Staking-Anforderungen des Deployers. Beispielsweise wird Stake, der für ein HIP-3-Deployment zählt, nicht doppelt für ein Outcome-Deployment angerechnet.
• Deployer müssen die Standard-Kontoabstraktion verwenden.

Die Deaktivierung setzt voraus, dass die Mindest-Staking-Dauer für Deployer (183 Tage) verstrichen ist und dass der Deployer keine aktiven Outcomes hat. Die Deaktivierung ist dauerhaft: Das Konto kann nicht erneut aktiviert werden, und sein Venue-Name bleibt reserviert.

Vorlagen

Jeder von einem Deployer erstellte Markt stammt aus einer Vorlage. Eine Vorlage hat eine von drei Rollen:

• Standalone Outcome: erstellt einen einzelnen YES/NO-Markt; die Vorlage legt die Seitennamen fest.
• Question: erstellt eine Question (den Container).
• Question Outcome: erstellt ein Outcome einer Question; jede Question-Outcome-Vorlage deklariert ihre übergeordnete Question-Vorlage, und Instanziierungen werden nur unter dieser übergeordneten Vorlage akzeptiert.

Eine Vorlage legt Anzeigenamen und Beschreibungstext mit {keyword}-Platzhaltern fest (z. B. "{underlying} above {target} at {expiry}"), zusammen mit einem typisierten hint pro Schlüsselwort. Eine Instanziierung liefert genau einen Wert pro Schlüsselwort.

Die Vorlagen-Metadaten enthalten ein semanticRestriction-Feld, das die beabsichtigte Semantik der aus der Vorlage instanziierten Märkte grob definiert. Märkte, die der semantischen Einschränkung ihrer Vorlage widersprechen, gelten als fehlerhaft und können von Validatoren durch Slashing sanktioniert werden.

Wertformate für Schlüsselwörter nach Hint-Typ:

Werte umfassen höchstens 100 Zeichen und dürfen {, } oder | nicht enthalten (: ist erlaubt, z. B. für HIP-3-Coin-Namen).

Auch der interpolierte Anzeigetext (Vorlagentext mit eingesetzten Werten) ist begrenzt: Namen umfassen höchstens 70 Zeichen für Standalone Outcomes und Questions sowie höchstens 25 Zeichen für Question Outcomes, und Standalone-Seitennamen höchstens 10 Zeichen.

Die On-Chain-Outcome-Beschreibungen werden aus der Instanziierung abgeleitet:

• Name: template:<template_id>, z. B. template:aaa. Das Präfix template: ist reserviert. Nur Vorlagen-Deployments können es erzeugen. Namen umfassen höchstens 100 Zeichen.
• Description: die nach Schlüsselwort sortierten Schlüsselwort-Wert-Paare, verbunden als keyword:value|keyword:value, z. B. expiry:20260801-0600|target:100|underlying:BTC. Beschreibungen umfassen höchstens 2000 Zeichen.
• Side names: bei Standalone Outcomes template: plus die Seitennamen der Vorlage (z. B. template:Over / template:Under); Question Outcomes verwenden die Standardwerte Yes / No.
• Question fallback: mit dem Namen template fallback, der Beschreibung other und den Seitennamen Yes / No.

Deployer-Fee-Scale

Vorlagen-Instanzen (registerStandaloneOutcomeFromTemplate und questionTemplateInstance von registerQuestionFromTemplate) enthalten ein erforderliches deployerFeeScale, eine Dezimalzeichenkette in [0, 10] (Deployer fee scale cannot be negative or greater than 10.).

• Nutzer, die auf den Märkten des Outcome handeln, zahlen den Basis-Outcome-Handelsgebührensatz multipliziert mit scale + max(scale, 1): Der Deployer erhält den scale-Anteil und das Protokoll den Rest. Bei "0" zahlen Nutzer den Basissatz und der Deployer erhält nichts. Maker-Rabatte werden auf Outcome-Märkten nie gezahlt.
• Der Scale einer Question gilt einheitlich für ihren Fallback und jedes Question Outcome, einschließlich später zugeordneter; Question-Outcome-Vorlagen-Instanzen tragen keinen eigenen Scale.
• Die Scales pro Outcome werden in der outcomeMeta-Info-Anfrage zurückgegeben.

Beispiele, ausgedrückt als Vielfache des Basis-Outcome-Handelsgebührensatzes des Nutzers:

Builder Codes

Builder Codes übernehmen für Verkaufsorders das Spot-Verhalten. Builder Codes können auch auf Kauforders für Outcome-Orders angewendet werden und werden ebenfalls im Quote-Token berechnet. Diese Builder-Gebühren werden vom Protokoll nach Best-Effort-Prinzip erhoben. Builder-Interfaces können bei der Berechnung der maximalen Ordergröße prüfen, ob das Quote-Token-Guthaben ausreicht.

Aktionsreferenz

registerStandaloneOutcomeFromTemplate

Erstellt einen eigenständigen YES/NO-Markt aus einer Standalone-Outcome-Vorlage.

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

registerQuestionFromTemplate

Erstellt eine Question und ihre Question Outcomes in einer einzigen Aktion.

{
  "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": [] }
      ]
    }
  }
}

• Jede Question-Outcome-Vorlage muss die Question-Vorlage als übergeordnete Vorlage deklarieren. Dieselbe Question-Outcome-Vorlage kann mehrfach mit unterschiedlichen Werten instanziiert werden.
• Eine Question mit N Question Outcomes registriert N + 1 Outcomes (der Fallback wird automatisch erstellt). Alle zählen auf das Limit aktiver Outcomes des Deployers.
• Weitere Question Outcomes können der aktiven Question mit registerAndAssociateNamedOutcomeFromTemplate hinzugefügt werden. Begrenzt auf höchstens 100 Question Outcomes pro Question.

registerAndAssociateNamedOutcomeFromTemplate

Fügt einer aktiven Question des Deployers ein Question Outcome hinzu.

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

• Die Question muss aus einer Vorlage erstellt worden sein, und die Question-Outcome-Vorlage muss die Vorlage der Question als übergeordnete Vorlage deklarieren.
• Das neue Outcome übernimmt den deployerFeeScale der Question und zählt auf die Limits für aktive Outcomes und das Tageslimit des Deployers.
• Inhaber des Fallback-YES-Tokens der Question erhalten ein gleich hohes Guthaben des YES-Tokens des neuen Outcome, sodass bestehende „other"-Positionen ihre Bedeutung behalten.

settleOutcome

Wickelt ein Outcome des Deployers ab.

{
  "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 und sideNames müssen exakt mit dem abzuwickelnden Outcome übereinstimmen.
• settleFraction ist eine Dezimalzahl in [0, 1]. Standalone Outcomes können zu einem beliebigen Anteil abgewickelt werden (z. B. "0.66" für skalare Auszahlungen); Outcomes, die zu einer Question gehören, müssen zu genau "0" oder "1" abgewickelt werden.
• details muss leer sein.
• Bei Question Outcomes erfolgt das Settlement sequenziell: Question Outcomes können in beliebiger Reihenfolge zu "0" abgewickelt werden. Ein einzelnes Outcome wird zu "1" abgewickelt, nachdem es das letzte aktive Question Outcome ist; dabei werden automatisch der Fallback auf 0 und die Question abgewickelt.

settleQuestion2

Wickelt alle verbleibenden Question Outcomes einer Question in einer einzigen Aktion ab. Hinweis: Die ursprüngliche Variante settleQuestion wird nicht mehr unterstützt.

{
  "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 muss genau die verbleibenden aktiven Question Outcomes der Question abdecken, wobei genau eines zu "1" und alle anderen zu "0" abgewickelt werden. Der Fallback wird automatisch auf 0 abgewickelt.

setSubDeployers

Erteilt oder entzieht Sub-Deployer-Berechtigungen.

{
  "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 }
    ]
  }
}

• Ein Sub-Deployer, dem eine Variante gewährt wurde, kann diese Aktion im Namen des Deployers senden: Registrierungen werden unter dem Venue des Deployers erstellt und zählen auf dessen Limits, und Settlements können sich nur auf die eigenen Outcomes und Questions des Deployers beziehen.
• variant ist eine von registerStandaloneOutcomeFromTemplate, registerQuestionFromTemplate, registerAndAssociateNamedOutcomeFromTemplate, settleOutcome oder settleQuestion. Die settleQuestion-Berechtigung autorisiert die Aktion settleQuestion2.
• allowed fügt den Nutzer zur autorisierten Menge für die Variante hinzu oder entfernt ihn daraus.

Lese-API

• Die Info-Anfrage {"type": "outcomeMeta"} enthält nicht-null Outcome-Deployer.
• Die Info-Anfrage {"type": "outcomeTemplates"} gibt alle Vorlagen zurück.

Limits

• Höchstens N aktive Outcomes pro Deployer (N=10 im Testnet). Das Abwickeln von Outcomes gibt Kapazität frei.
• Ein Deployer kann M Outcomes pro Tag erstellen (M=50 im Testnet).