HIP-4 디플로이어 작업

테스트넷 전용

개요

시장의 품질과 정의 명확성을 보장하기 위해 검증인들이 아웃컴 템플릿에 대해 투표하며, HIP-4 디플로이어는 이를 퍼미션리스 배포의 기반으로 사용합니다. 템플릿은 사양의 표시 텍스트, 사이드 이름, 타입이 지정된 키워드 집합의 구조를 고정합니다.

배포에는 가스 비용이 없습니다. 대신 용량은 디플로이어별 한도로 제한됩니다(한도 참조).

액션 형식

배포에는 다음 액션들이 관련됩니다:

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

• 아웃컴과 질문은 생성 시 할당된 숫자 인덱스로 참조됩니다(예: "outcome": 7).
• Venue: 모든 outcomeDeploy 액션은 필수 최상위 venue 필드를 가지며, 이는 디플로이어의 venue 이름이어야 합니다(HIP-3 디플로이어 액션의 dex 필드와 유사). 서브 디플로이어 액션은 자신이 대행하는 디플로이어의 venue를 전달하며, 정산은 해당 venue 디플로이어의 아웃컴과 질문만 대상으로 해야 합니다.
• Venue 이름: 소문자 ASCII 2–4자이며, HIP-3 펍 DEX 이름과 동일한 규칙이 적용됩니다. 이름은 비활성화된 디플로이어(이름은 계속 예약됨)를 포함한 모든 디플로이어의 venue 이름 전체에서 고유해야 하며, 기존 펍 DEX 이름(및 spot)과 일치해서는 안 됩니다. 반대로, 등록된 venue 이름은 이후의 펍 DEX 배포가 사용할 수 없습니다.
• HIP-3과 마찬가지로, 모든 튜플 리스트는 서명 전에 사전순으로 정렬해야 합니다
• keywordToValue는 각 템플릿 키워드를 해당 값에 매핑하는 정렬된 튜플 리스트입니다. 예: [["expiry","20260801-0600"],["target","100"],["underlying","ABC"]].
• 이름 및 설명 값은 2요소 배열입니다: ["<name>", "<description>"].
• sideNames 배열은 ["<YES side name>", "<NO side name>"]입니다.
• 수량과 정산 비율은 십진수 문자열입니다("1", "0.25").

활성화

activateOutcomeDeployer는 activate와 deactivate 배리언트를 가진 enum입니다:

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

• 스테이킹 요건: 활성 디플로이어는 아웃컴 디플로이어로 남아 있는 동안 스테이킹 요건을 유지해야 합니다. 요건은 디플로이어의 다른 스테이킹 요건과 합산됩니다. 예를 들어, HIP-3 배포에 사용되는 스테이크는 아웃컴 배포에 이중으로 계산되지 않습니다.
• 디플로이어는 Standard 계정 추상화를 사용해야 합니다.

비활성화하려면 최소 디플로이어 스테이킹 기간(183일)이 경과했고 디플로이어에게 활성 아웃컴이 없어야 합니다. 비활성화는 영구적입니다. 해당 계정은 다시 활성화할 수 없으며, 해당 venue 이름은 계속 예약됩니다.

템플릿

모든 디플로이어 생성 시장은 템플릿에서 나옵니다. 템플릿은 세 가지 역할 중 하나를 가집니다:

• 독립 아웃컴: 단일 YES/NO 시장을 배포합니다. 템플릿이 사이드 이름을 고정합니다.
• 질문: 질문(컨테이너)을 배포합니다.
• 질문 아웃컴: 질문의 아웃컴 하나를 배포합니다. 각 질문 아웃컴 템플릿은 자신의 부모 질문 템플릿을 선언하며, 인스턴스화는 해당 부모 아래에서만 허용됩니다.

템플릿은 {keyword} 플레이스홀더(예: "{underlying} above {target} at {expiry}")를 포함하는 표시 이름과 설명 텍스트, 그리고 키워드별 타입이 지정된 hint를 고정합니다. 인스턴스화는 각 키워드에 정확히 하나의 값을 제공합니다.

템플릿 메타데이터에는 semanticRestriction 필드가 있으며, 이는 해당 템플릿에서 인스턴스화되는 시장의 의도된 의미론을 광범위하게 정의합니다. 템플릿의 의미 제한과 모순되는 시장은 잘못된 형식으로 간주되며 검증인의 슬래싱 대상이 됩니다.

힌트 타입별 키워드 값 형식:

값은 최대 100자이며 {, }, |를 포함할 수 없습니다(:는 허용됨, 예: HIP-3 코인 이름).

보간된 표시 텍스트(값이 대체된 템플릿 텍스트)에도 제한이 있습니다. 이름은 독립 아웃컴과 질문의 경우 최대 70자, 질문 아웃컴의 경우 최대 25자이며, 독립 사이드 이름은 최대 10자입니다.

온체인 아웃컴 설명은 인스턴스화에서 파생됩니다:

• 이름: template:<template_id>, 예: template:aaa. template: 접두사는 예약되어 있습니다. 템플릿 배포만 이를 생성할 수 있습니다. 이름은 최대 100자입니다.
• 설명: 키워드 기준으로 정렬된 키워드-값 쌍을 keyword:value|keyword:value로 결합한 것, 예: expiry:20260801-0600|target:100|underlying:BTC. 설명은 최대 2000자입니다.
• 사이드 이름: 독립 아웃컴의 경우 template:에 템플릿의 사이드 이름을 덧붙인 것(예: template:Over / template:Under). 질문 아웃컴은 기본값 Yes / No를 사용합니다.
• 질문 폴백: 이름은 template fallback, 설명은 other, 사이드 이름은 Yes / No.

디플로이어 수수료 스케일

템플릿 인스턴스(registerStandaloneOutcomeFromTemplate 및 registerQuestionFromTemplate의 questionTemplateInstance)는 필수 deployerFeeScale을 가지며, 이는 [0, 10] 범위의 십진수 문자열입니다(Deployer fee scale cannot be negative or greater than 10.).

• 아웃컴의 시장을 거래하는 사용자는 기본 아웃컴 거래 수수료율에 scale + max(scale, 1)을 곱한 수수료를 지불합니다. scale 부분은 디플로이어가 받고 나머지는 프로토콜이 받습니다. "0"인 경우 사용자는 기본 요율을 지불하며 디플로이어는 아무것도 받지 않습니다. 아웃컴 시장에서는 메이커 리베이트가 지급되지 않습니다.
• 질문의 스케일은 폴백과 모든 질문 아웃컴(이후 연결된 것 포함)에 균일하게 적용됩니다. 질문 아웃컴 템플릿 인스턴스는 자체 스케일을 가지지 않습니다.
• 아웃컴별 스케일은 outcomeMeta 정보 요청에서 반환됩니다.

예시(사용자의 기본 아웃컴 거래 수수료율의 배수로 표현):

Builder codes

Builder codes는 매도 주문에 대해 스팟 동작을 상속합니다. Builder codes는 아웃컴 주문의 매수 주문에도 적용될 수 있으며, 호가 토큰으로 청구됩니다. 이 빌더 수수료는 프로토콜이 best-effort 방식으로 청구합니다. 빌더 인터페이스는 최대 주문 크기를 계산할 때 충분한 호가 토큰 잔액이 있는지 검증할 수 있습니다.

액션 레퍼런스

registerStandaloneOutcomeFromTemplate

독립 아웃컴 템플릿에서 독립 YES/NO 시장을 배포합니다.

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

registerQuestionFromTemplate

하나의 액션으로 질문과 질문 아웃컴을 배포합니다.

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

• 각 질문 아웃컴 템플릿은 해당 질문 템플릿을 부모로 선언해야 합니다. 동일한 질문 아웃컴 템플릿을 서로 다른 값으로 여러 번 인스턴스화할 수 있습니다.
• 질문 아웃컴 N개를 가진 질문은 N + 1개의 아웃컴을 등록합니다(폴백이 자동 생성됨). 모두 디플로이어의 활성 아웃컴 한도에 포함됩니다.
• registerAndAssociateNamedOutcomeFromTemplate로 라이브 질문에 더 많은 질문 아웃컴을 추가할 수 있습니다. 질문당 질문 아웃컴은 최대 100개입니다.

registerAndAssociateNamedOutcomeFromTemplate

디플로이어의 라이브 질문에 질문 아웃컴 하나를 추가합니다.

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

• 해당 질문은 템플릿에서 배포되었어야 하며, 질문 아웃컴 템플릿은 해당 질문의 템플릿을 부모로 선언해야 합니다.
• 새 아웃컴은 질문의 deployerFeeScale을 상속하며, 디플로이어의 활성 아웃컴 한도와 일일 한도에 포함됩니다.
• 질문의 폴백 YES 토큰 보유자는 새 아웃컴의 YES 토큰을 동일한 잔액만큼 받으므로, 기존 "other" 포지션은 의미를 유지합니다.

settleOutcome

디플로이어의 아웃컴 하나를 정산합니다.

{
  "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과 sideNames는 정산 대상 아웃컴과 정확히 일치해야 합니다.
• settleFraction은 [0, 1] 범위의 십진수입니다. 독립 아웃컴은 임의의 비율로 정산될 수 있고(예: 스칼라 지급을 위한 "0.66"), 질문에 속한 아웃컴은 정확히 "0" 또는 "1"로 정산되어야 합니다.
• details는 비어 있어야 합니다.
• 질문 아웃컴의 정산은 순차적입니다. 질문 아웃컴은 어떤 순서로든 "0"으로 정산될 수 있습니다. 단일 아웃컴은 마지막 활성 질문 아웃컴이 된 후에 "1"로 정산되며, 이때 폴백이 자동으로 0으로 정산되고 질문이 정산됩니다.

settleQuestion2

하나의 액션으로 질문에 남은 질문 아웃컴을 모두 정산합니다. 참고: 원래의 settleQuestion 배리언트는 폐기되었습니다.

{
  "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는 질문에 남은 활성 질문 아웃컴을 정확히 포함해야 하며, 정확히 하나가 "1"로 정산되고 나머지는 모두 "0"으로 정산되어야 합니다. 폴백은 자동으로 0으로 정산됩니다.

setSubDeployers

서브 디플로이어 권한을 부여하거나 취소합니다.

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

• 배리언트를 부여받은 서브 디플로이어는 디플로이어를 대신해 해당 액션을 보낼 수 있습니다. 등록은 디플로이어의 venue 아래 생성되어 디플로이어의 한도에 포함되며, 정산은 디플로이어 자신의 아웃컴과 질문만 대상으로 할 수 있습니다.
• variant는 registerStandaloneOutcomeFromTemplate, registerQuestionFromTemplate, registerAndAssociateNamedOutcomeFromTemplate, settleOutcome, settleQuestion 중 하나입니다. settleQuestion 부여는 settleQuestion2 액션을 승인합니다.
• allowed는 해당 배리언트의 승인 집합에서 사용자를 추가하거나 제거합니다.

읽기 API

• {"type": "outcomeMeta"} 정보 요청에 null이 아닌 아웃컴 디플로이어가 포함됩니다.
• {"type": "outcomeTemplates"} 정보 요청은 모든 템플릿을 반환합니다.

한도

• 디플로이어당 최대 N개의 활성 아웃컴(테스트넷에서 N=10). 아웃컴을 정산하면 용량이 확보됩니다.
• 디플로이어는 하루에 M개의 아웃컴을 배포할 수 있습니다(테스트넷에서 M=50).