# 제네시스 할당 메커니즘

Genesis Launches는 총 약정 포인트와 약정된 $VIRTUAL 총량에 따라 자동으로 규모가 커지는 동적 단계형 모집 구조를 사용합니다.

* 모집 한계는 21,000, 42,000, 100,000 $VIRTUAL입니다.
* 약정이 기준치를 초과하면 모금은 다음 단계로 확장됩니다.
* 가장 높은 한계를 초과한 모든 기여분은 자동으로 환불됩니다.

각 참가자의 할당량은 상대적으로 약정한 포인트를 기준으로 하며, 지갑당 최대 566 $VIRTUAL 약정 한도가 적용됩니다.

***

## 작동 방식

각 Genesis Launch는 다음 흐름을 따릅니다:

1. 사용자는 프리세일에 참여하기 위해 포인트를 약정합니다.
2. 시스템은 모든 사용자가 약정한 총 포인트를 바탕으로 예상 할당량을 계산합니다.
3. 사용자는 자신이 약정한 포인트 수로 결정되는 최대 할당 가능성에 대한 예상 비용과 맞추기 위해 $VIRTUAL을 약정하라는 안내를 받습니다.
4. 총 약정이 한계에 도달하면 모집 규모는 다음 단계로 올라갑니다.
5. 최종 모집 규모는 24시간 기간 동안 도달한 가장 높은 단계에서 고정됩니다.

이로써 할당 규모가 사용자 참여도를 반영하는 실시간의 투명한 조정 환경이 만들어집니다.

***

## 핵심 규칙

| 매개변수               | 값                            |
| ------------------ | ---------------------------- |
| 사용자 최대 할당량         | 566 $VIRTUAL(1% 세금 포함)       |
| 진입당 최대 $VIRTUAL 약정 | 566 $VIRTUAL(1% 세금 포함)       |
| 할당 로직              | 전체 풀 대비 약정된 포인트 기준           |
| 환불                 | 사용되지 않은 $VIRTUAL과 포인트는 자동 환불 |

사용자가 다른 사람들보다 더 많은 포인트를 약정하면, 지갑당 566 $VIRTUAL의 약정 한도에 의해 제한되는 범위 내에서 Genesis 공급량의 더 큰 비례 몫을 받게 됩니다.

사용자는 포인트를 약정하는 동시에 계산된 $VIRTUAL 금액도 약정해야 합니다. 둘 중 하나라도 부족하면 시스템은 해당 참여를 स्वीकार하지 않습니다.

총 약정이 한계를 넘으면 모집 규모는 올라갑니다(21K → 42K → 100K). 최종 모집 규모는 24시간 이내에 도달한 가장 높은 단계에서 고정됩니다.

사용되지 않은 $VIRTUAL은 자동으로 환불되며, 여기에는 (a) 최종 할당량이 약정보다 적은 경우와 (b) 최종적으로 도달한 모집 단계 상한을 초과한 금액이 포함됩니다.

***

## 실시간 피드백

Genesis 인터페이스는 다음을 표시합니다:

* 풀 전체에 약정된 총 포인트
* 상위 참가자를 보여주는 리더보드
* 총 약정된 $VIRTUAL
* 현재 값을 기준으로 한 예상 할당 범위
* 현재 모집 단계와 한계

***

## 동적 조정 기간

할당량은 동적이며 24시간 프리세일 동안 새로운 참가자가 풀에 들어오면 조정됩니다.

* 추가 사용자가 포인트를 약정하면 예상 할당량이 감소할 수 있습니다.
* 전체 약정이 증가하면 총 모집 규모가 더 높은 단계(21K → 42K → 100K)로 이동하여 더 큰 할당 풀을 열 수 있습니다. 일단 약정이 제출되면 고정되며 줄이거나 철회할 수 없습니다. 참가자는 24시간 프리세일 기간 동안 추가 약정을 할 수 있지만, 기존 약정을 조정하거나 제거할 수는 없습니다. 가장 높은 단계의 최대 한도를 초과한 모든 약정은 자동으로 환불됩니다.
* 참가자는 기간이 끝나기 전까지 언제든지 포인트와 $VIRTUAL 약정을 늘릴 수 있습니다.

{% hint style="danger" %}
최종 할당에서 희석을 피하고 싶다면 프리세일 동안 포인트와 $VIRTUAL의 추가 약정을 제출할 수 있습니다. 한 번 약정이 이루어지면 고정되어 줄이거나 철회할 수 없지만, 참가자는 24시간 기간 내 언제든지 더 추가할 수 있습니다.
{% endhint %}

이 구조는 프리세일 전반에 걸쳐 유연성을 유지하면서도 초기의 적극적인 참여를 장려합니다.

***

## 토크노믹스 구조

각 Genesis Launch는 표준화된 토큰 배분 프레임워크를 따릅니다:

| 구성 요소                 | 할당량(%) |
| --------------------- | ------ |
| 프리세일                  | 7%     |
| 유동성 풀(LP)             | 6%     |
| veVIRTUAL 보유자 대상 에어드롭 | 2%     |
| 개발 / 재무 / 마케팅 /       | 85%    |

***

## FDV 구조: 약정 vs. 시장

모든 Genesis 출시에서는 설계상 두 개의 FDV(완전희석가치)가 정의됩니다. 하나는 약정 단계에서, 다른 하나는 시장 배포 시점에서입니다. 각각은 에이전트 생애주기에서 서로 다른 역할을 합니다.

### Genesis 약정 FDV: 동적(단계 기반)

24시간 약정 기간 동안 Virgens는 전체 토큰 공급량의 7%를 받는 대가로 포인트와 $VIRTUAL을 기여합니다.

이는 최종적으로 도달한 단계에 따라 달라지는 암시적 출시 전 FDV를 설정합니다:

* 1단계(21,000 $VIRTUAL 약정): 21,000 ÷ 0.07 = 300,000 $VIRTUAL FDV
* 2단계(42,000 $VIRTUAL 약정): 42,000 ÷ 0.07 = 600,000 $VIRTUAL FDV
* 3단계(100,000 $VIRTUAL 약정): 100,000 ÷ 0.07 = 1,428,571 $VIRTUAL FDV

규칙:

* 1단계(21,000 $VIRTUAL)에 도달하지 못하면 출시가 취소되며 모든 자금과 포인트는 전액 환불됩니다.
* 약정이 2단계(42,000 $VIRTUAL)를 초과하지만 3단계(100,000 $VIRTUAL)에 도달하지 못하면, 약정 FDV는 2단계(600k FDV)에서 고정됩니다.

### 시장 FDV: 6% 유통량 기준 고정

Genesis 출시가 성공하면 총 토큰 공급량의 6%가 약정된 $VIRTUAL과 쌍을 이루어 유동성 풀에 배포됩니다.

이로써 단계와 관계없이 항상 6% 공급량을 기준으로 계산되는 시장 FDV가 만들어집니다:

* 1단계(21k): 21,000 ÷ 0.06 = 350,000 $VIRTUAL FDV
* 2단계(42k): 42,000 ÷ 0.06 = 700,000 $VIRTUAL FDV
* 3단계(100k): 100,000 ÷ 0.06 = 1,666,667 $VIRTUAL FDV

### 이것이 중요한 이유:

이 이중 FDV 구조는 의도된 것입니다:

* 약정 FDV(7% 공급): Virgens가 더 낮은 암시적 가치평가로 진입할 수 있게 하여 초기 확신에 보상합니다.
* 시장 FDV(6% 공급): 1일부터 견고한 유동성 기반을 구축하여 더 원활한 가격 발견과 시장 안정성을 보장합니다.

***


---

# Agent Instructions: 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:

```
GET https://whitepaper.virtuals.io/virtuals-protocol-whitepaper-ko/builders-hub/genesis-launch/genesis-allocation-mechanics.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.