a16z: 프로토콜 토큰은 어떻게 현금 흐름을 생성하는가?

작성자: a16z Crypto

편집: Pzai, Foresight News

기반 시설 토큰에 대해서는------제 1 계층 네트워크(또는 계산 스택의 인접 부분, 예: Layer 2)------그 경제 모델이 충분히 개발되고 이해되었으며 블록 공간의 수요와 공급에 뿌리를 두고 있습니다. 그러나 프로토콜 토큰(App Token)------블록체인 위에 서비스를 배포하는 스마트 계약 프로토콜이며 "분산 비즈니스" 내에서 권리를 상속하는------의 경우, 경제 모델의 구축은 여전히 탐색 중입니다.

프로토콜 토큰의 비즈니스 모델은 그 기반 소프트웨어만큼이나 표현력이 있어야 합니다. 이를 위해 우리는 프로토콜 토큰의 현금 흐름을 도입합니다------이 방법은 프로토콜이 느슨하고 유연한 모델을 생성할 수 있게 하며, 사용자는 제공하는 가치에 따라 보상을 받을 방법을 선택할 수 있습니다. 이 방법은 다양한 관할권의 규제 요구 사항에 따라 규정 준수 활동에서 수수료를 발생시켜 더 높은 규정 준수를 장려합니다. 또한 프로토콜이 생성하는 가치를 극대화하면서 거버넌스를 최소화하도록 장려합니다.

여기서 공유하는 원칙은 모든 Web3 프로토콜에 적용됩니다------DeFi에서 분산형 소셜, DePIN 네트워크 및 그 사이의 모든 곳까지.

토큰 모델이 직면한 도전

기반 시설 토큰은 내재된 수요와 공급의 영향을 받습니다: 수요가 증가함에 따라 공급이 감소하고 시장도 이에 따라 조정됩니다. EIP-1559는 많은 기반 시설 토큰의 원주율 경제 기반을 가속화했으며, 이 제안은 모든 이더리움 거래에 대한 기본 수수료 소각을 시행했습니다. 그러나 구매 및 소각 모델에 대한 산발적인 시도가 있었음에도 불구하고 프로토콜 토큰에 대해서는 EIP-1559와 동등한 시도가 없었습니다.

프로토콜은 블록 공간의 사용자이지 제공자가 아니므로, 그들은 블록 공간을 사용하는 다른 사람에게 가스 요금을 부과하는 데 의존할 수 없습니다. 이것이 그들이 자신의 경제 모델을 개발해야 하는 이유입니다.

여기에는 몇 가지 법적 도전도 존재합니다: 전형적인 블록체인 거래의 일반적인 특성과 그들이 사용하는 프로그래밍 메커니즘으로 인해 기반 시설 토큰 경제 모델은 법적 위험의 영향을 덜 받습니다. 그러나 프로토콜 토큰 경제 모델의 경우, 관련된 프로토콜은 규정 준수 활동의 촉진에 의존할 수 있으며, 이는 거버넌스 토큰 보유자의 개입이 필요할 수 있어 경제학을 더욱 복잡하게 만듭니다. 파생상품 거래를 촉진하는 분산형 거래소는 미국에서 고도로 규제되는 활동이며, 이더리움과는 전혀 다릅니다.

이러한 내재적 및 외부적 도전의 결합은 프로토콜 토큰이 다른 경제 모델을 필요로 함을 의미합니다. 이를 염두에 두고, 우리는 프로토콜 수익을 극대화하고 규제 준수를 장려하며 거버넌스를 최소화하는 동시에 프로토콜 토큰 보유자에게 서비스를 제공하는 방법으로 프로토콜을 설계하는 가능성 있는 솔루션을 제안합니다. 우리의 목표는 간단합니다: 현금 흐름을 통해 프로토콜 토큰에 많은 기반 시설 토큰이 이미 갖추고 있는 것과 동일한 경제 기반을 제공합니다.

우리의 솔루션은 프로토콜 토큰이 직면한 세 가지 문제를 해결하는 데 중점을 두고 있으며, 이는 다음과 관련이 있습니다: 거버넌스 측면의 도전, 가치 분배의 도전 및 규정 준수 활동의 도전.

거버넌스 측면의 도전

프로토콜 토큰은 일반적으로 거버넌스 권한을 가지며, 분산 자치 조직(DAO)의 존재는 기반 시설 토큰이 직면하지 않는 불확실성을 초래할 수 있습니다. 미국에서 많은 비즈니스를 하는 DAO의 경우, DAO가 프로토콜 수익을 통제하거나 프로토콜의 경제 활동에 개입하여 이러한 활동을 프로그래밍 방식으로 만들 경우 위험이 발생할 수 있습니다. 이러한 위험을 피하기 위해, 프로젝트는 거버넌스를 최소화하여 DAO의 통제권을 제거할 수 있습니다. 이를 수행할 수 없는 DAO의 경우, 와이오밍주 새로운 분산형 비법인 비영리 협회(DUNA)는 이러한 위험을 완화하고 적용 가능한 세법을 준수하는 데 도움이 될 수 있는 분산형 법적 실체를 제공합니다.

가치 분배의 도전

프로토콜은 토큰 보유자에게 가치를 분배하는 메커니즘을 설계할 때 신중하게 행동해야 합니다. 미국 증권법에 따르면, 투표권과 경제적 권리를 결합하는 것은 특히 비례 분배 및 토큰 구매 및 소각과 같은 간단하고 직접적인 메커니즘에 대해 우려를 불러일으킬 수 있습니다. 이러한 메커니즘은 배당금 및 자사주 매입과 유사해 보이며, 이는 토큰이 주식과는 다른 규제 프레임워크를 가져야 한다는 주장을 약화시킬 수 있습니다.

대신, 프로젝트는 이해관계자 자본주의를 탐색해야 합니다------프로젝트에 유리한 방식으로 토큰 보유자의 기여를 보상하는 것입니다. 많은 프로젝트가 전방 운영(Liquity), 프로토콜 참여(Goldfinch) 및 안전 모듈의 일부로 담보를 스테이킹하는 것(Aave)을 포함하여 긍정적이고 참여를 장려합니다. 여기서 디자인 공간은 열려 있지만, 좋은 출발점은 프로젝트 내의 모든 이해관계자를 도식화하고 각 이해관계자가 어떤 행동을 장려해야 하는지 결정하며, 프로토콜이 이러한 인센티브를 통해 어떤 총 가치를 창출할 수 있는지를 결정하는 것입니다.

간단히 말해, 이 글에서는 다른 계획이 존재하더라도 거버넌스에 참여하는 토큰 보유자에게 보상을 제공하는 간단한 보상 모델을 가정하겠습니다.

규정 준수 활동의 도전

토큰 보유자를 위한 가치 축적 메커니즘을 설계할 때, 규정 준수 활동을 촉진하는 프로토콜도 신중해야 합니다. 이러한 메커니즘이 적용 가능한 법률에 따라 운영되지 않는 프론트엔드 또는 API에서 가치를 생성하지 않는 경우, 토큰 보유자는 불법 활동에서 이익을 얻을 수 있습니다.

이 문제에 대한 대부분의 제안된 솔루션은 미국에서 허용되는 활동의 가치 축적을 제한하는 데 집중합니다------예를 들어, 특정 자산과 관련된 유동성 풀에 대해서만 프로토콜 수수료를 부과하는 것입니다. 이는 프로젝트가 규제 접근 방식의 최소 공통 분모에 얽매이게 하며, 전 세계 자율 소프트웨어 프로토콜의 가치 제안을 훼손합니다. 또한 거버넌스 최소화 노력을 직접적으로 방해합니다. 규제 준수 관점에서 어떤 요금 전략이 효과적인지를 결정하는 것은 DAO에 적합한 작업이 아닙니다.

이상적인 세계에서는 프로젝트가 해당 활동을 허용하는 모든 관할권의 활동에서 수수료를 부과할 수 있어야 하며, DAO에 의존하여 무엇이 허용되는지를 결정할 필요가 없습니다. 솔루션은 프로토콜 수준에서 규정을 준수하도록 요구하는 것이 아니라, 수수료를 발생시키는 프론트엔드 또는 API가 프론트엔드의 위치에 적용 가능한 법률 및 규정을 준수할 때만 프로토콜이 발생시킨 수수료가 전가되도록 보장하는 것입니다. 만약 미국에서 프로토콜이 촉진하는 특정 유형의 거래에 대해 수수료를 부과하는 것이 불법으로 규정된다면, 이는 해당 프로토콜 토큰의 경제적 가치를 제로로 떨어뜨릴 수 있으며, 해당 활동이 세계의 모든 다른 국가에서 완전히 허용되더라도 마찬가지입니다. 수수료 축적 및 분배의 유연성은 궁극적으로 규제 압박에 직면했을 때의 탄력성과 같습니다.

핵심 문제: 수수료 추적 가능성

수수료의 추적 가능성은 비규정 준수 프론트엔드에서 발생할 수 있는 잠재적 위험을 해결하는 데 필수적이며, 동시에 검열 위험을 도입하거나 프로토콜에 대한 허가를 요구하지 않아야 합니다. 추적 가능성을 통해 프로토콜은 토큰 보유자가 발생시키는 모든 수수료가 토큰 보유자가 있는 관할권에서 합법적으로 준수하는 프론트엔드에서만 발생하도록 보장할 수 있습니다. 만약 수수료가 추적할 수 없다면, 토큰 보유자는 비규정 준수 프론트엔드(즉, 비규정 준수 프론트엔드에서 발생한 수수료)에서 가치를 발생시킬 수 없으며, 이는 토큰 보유자에게 위험을 초래할 수 있습니다.

수수료를 추적 가능하게 만들기 위해, 프로토콜은 두 단계 프로토콜 토큰 스테이킹 시스템 디자인을 사용할 수 있습니다.

• 1단계: 어떤 프론트엔드가 수수료를 발생시키는지 확인합니다.
• 2단계: 사용자 정의 논리에 따라 수수료를 다양한 풀로 라우팅합니다.

프론트엔드 매핑

수수료의 추적 가능성은 도메인과 공개 키/비공개 키 쌍 간의 일대일 매핑이 필요합니다. 이 매핑이 없으면 악의적인 프론트엔드가 거래를 속이고 정직한 도메인에서 제출된 것처럼 가장할 수 있습니다. 암호학을 통해 우리는 프론트엔드를 "등록"하고 도메인에서 공개 키로의 매핑을 불변적으로 기록하여 도메인이 실제로 해당 공개 키를 제어하고 있음을 증명하며, 해당 비공개 키로 거래에 서명합니다. 이를 통해 우리는 거래를 특정 도메인에 귀속시킬 수 있으며, 따라서 수수료를 특정 도메인에 귀속시킬 수 있습니다.

수수료 경로

수수료의 출처가 추적 가능해지면, 프로토콜은 이러한 수수료를 어떻게 분배할 것인지 결정할 수 있으며, 이는 토큰 보유자가 불법 거래 수수료의 영향을 받지 않도록 하면서도 DAO의 분산 거버넌스 부담을 증가시키지 않습니다. 이를 설명하기 위해, 우리는 각 프론트엔드에 대해 하나의 스테이킹 풀에서 모든 프론트엔드에 대해 하나의 스테이킹 풀까지의 프로토콜 토큰 스테이킹의 가능한 디자인 범위를 고려할 수 있습니다.

가장 간단한 구조에서, 각 프론트엔드의 수수료는 특정 프론트엔드 스테이킹 모듈로 라우팅될 수 있습니다. 토큰 보유자는 스테이킹할 프론트엔드를 선택함으로써 어떤 수수료를 수령하고, 토큰 보유자를 법적 위험에 처하게 하는 수수료를 피할 수 있습니다. 예를 들어, 토큰 보유자는 유럽에서 모든 규제 승인을 받은 프론트엔드와 관련된 모듈만 스테이킹할 수 있습니다. 이러한 디자인은 간단하게 들리지만, 실제로는 상당히 복잡합니다. 50개의 서로 다른 프론트엔드가 50개의 스테이킹 풀을 가질 수 있으며, 수수료의 희석은 토큰 가치에 부정적인 영향을 미칠 수 있습니다.

반면, 각 프론트엔드에서 발생한 수수료를 통합할 수 있지만, 이는 수수료의 추적 가능성 목적에 반합니다. 모든 수수료가 통합되면 규정 준수 및 비규정 준수 프론트엔드 수수료를 구분할 수 없게 됩니다------한 마리 쥐가 모든 것을 망칠 수 있습니다. 토큰 보유자는 수수료를 전혀 받지 않거나 풀에서 지분을 보유하는 것 중에서 선택해야 하며, 이는 그들이 관할권 내 비규정 준수 프론트엔드의 불법 활동에서 이익을 얻는 것을 의미합니다------이 선택은 많은 토큰 보유자가 참여하는 것을 막거나 시스템을 현재의 차선책 디자인으로 되돌릴 수 있습니다, 즉 DAO가 수수료를 어디에서 수집할 수 있는지를 평가해야 합니다.

큐레이션을 통한 수수료 추적 가능성 문제 해결

이러한 복잡성은 큐레이션을 통해 해결할 수 있습니다. 허가가 필요 없는 스마트 계약 프로토콜을 고려해 보십시오. 이 프로토콜에는 수수료와 토큰이 있습니다. 누구나 프로토콜을 위한 프론트엔드를 생성할 수 있으며, 각 프론트엔드는 자체 스테이킹 모듈을 가질 수 있습니다. 우리는 이 프로토콜의 하나의 프론트엔드를 app.xyz라고 부릅니다.

App.xyz는 해당 관할권의 특정 규정 준수 규칙을 따를 수 있습니다. app.xyz에서 발생하는 프로토콜 활동은 프로토콜 수수료를 발생시킵니다. App.xyz는 자체 스테이킹 모듈을 가지고 있으며, 토큰 보유자는 해당 모듈에 직접 토큰을 스테이킹하거나, 자신이 생각하는 규정 준수 프론트엔드의 선택된 집합을 큐레이션하는 큐레이터에게 토큰을 스테이킹할 수 있습니다. 이러한 토큰 스테이커는 자신이 스테이킹한 프론트엔드 집합에서 수수료 형태로 수익을 얻습니다. 만약 프론트엔드가 100달러의 수수료를 발생시키고, 100개의 개체가 각각 1개의 토큰을 스테이킹하면, 각 개체는 1달러를 받을 권리가 있습니다. 큐레이터는 처음에 자신의 서비스에 대해 수수료를 부과할 수 있습니다. 미래에는 정부가 체인 상에서 증명을 통해 해당 프론트엔드가 관할권 내에서 규정 준수를 입증하여 소비자를 보호하는 데 도움을 줄 수 있으며, 큐레이션의 자동화라는 부가적인 이점이 있습니다.

이 모델의 잠재적 위험 중 하나는 비규정 준수 프론트엔드의 운영 비용이 더 낮을 수 있다는 것입니다. 이는 규정 준수 프론트엔드의 관리 비용이 없기 때문입니다. 그들은 또한 거래자에게 프론트엔드 수수료를 환급하는 모델을 설계하여 그들의 해결책을 더욱 장려할 수 있습니다. 이러한 위험을 줄일 수 있는 두 가지 요소가 있습니다. 첫째, 대부분의 사용자는 실제로 규정 준수 프론트엔드가 현지 법률 및 규정을 준수하기를 원합니다. 이는 특히 대규모 규제 기관에 해당됩니다. 둘째, 규칙을 반복적으로 위반하고 프로토콜의 생존 가능성을 위협하는 비규정 준수 프론트엔드에 대해서는 거버넌스가 중요한 역할을 할 수 있으며, 이는 마지막 수단 또는 "거부권"으로서 나쁜 행동을 차단할 수 있습니다.

마지막으로, 등록된 프론트엔드에서 발생하지 않은 모든 거래 수수료는 포괄적인 스테이킹 모듈에 입금되어 프로토콜이 로봇이 시작한 거래 및 프로토콜 스마트 계약과의 기타 직접 상호작용에서 수익을 얻을 수 있도록 합니다.

이론에서 실행으로: 방법을 실천에 옮기기

프로토콜 토큰 스택에 대해 더 자세히 살펴보겠습니다. 프론트엔드 스테이킹을 촉진하는 프로토콜은 프론트엔드가 등록해야 하는 등록 스마트 계약을 구축해야 합니다.

1. 각 프론트엔드 또는 API는 자신의 도메인의 DNS 기록에 특별한 TXT 레코드를 추가할 수 있습니다. 예를 들어, ENS DNS 통합과 같은 방식입니다. 이 TXT 레코드는 프론트엔드가 한 번 생성하는 키 쌍의 공개 키를 포함하며, 이를 인증서라고 합니다.
2. 그런 다음 프론트엔드 클라이언트는 register 함수를 호출하고 자신의 도메인을 소유하고 있음을 증명하여 도메인과 인증서 공개 키 간의 매핑을 저장합니다.
3. 클라이언트를 통해 거래를 생성할 때, 해당 거래의 유효한 페이로드에 대해 인증서 공개 키로 서명합니다. 이들은 프로토콜의 스마트 계약에 번들 형태로 전달됩니다.
4. 프로토콜의 스마트 계약은 인증서를 검증하고, 그것이 올바른 거래 주체(프론트엔드)에 해당하는지 확인하며, 등록되었는지 확인합니다. 그렇다면 거래를 처리합니다. 그런 다음 거래에서 발생한 수수료는 도메인 이름(등록 기관에서)과 함께 FeeCollector(수수료 수집) 계약으로 전송됩니다.
5. FeeCollector(수수료 수집) 계약은 큐레이터, 사용자, 검증자 및 기타가 특정 도메인 또는 도메인 집합에 직접 토큰을 스테이킹할 수 있도록 합니다. 이러한 계약은 각 도메인에서 스테이킹된 토큰 수, 각 주소의 해당 스테이킹에서의 지분 및 스테이킹된 시간을 추적해야 합니다. 유동성 채굴의 일반적인 구현은 이러한 계약 논리의 출발점이 될 수 있습니다.
6. 큐레이터(또는 수수료 관리 계약 자체)에 스테이킹하는 사용자는 도메인에 스테이킹한 프로토콜 토큰 금액에 따라 비례적으로 수수료 지분을 추출할 수 있습니다. 이 구조는 Meta Morpho/Morpho Blue와 유사할 수 있습니다.

이 메커니즘은 프로토콜 DAO의 거버넌스 부담을 증가시키지 않으면서 도입될 수 있습니다. 사실, 거버넌스 책임은 줄어들 수 있습니다. 왜냐하면 우리는 프로토콜이 촉진하는 모든 거래에 대해 수수료 스위치를 영구적으로 열 수 있기 때문입니다. 이는 DAO가 프로토콜 경제 모델에 대한 어떤 통제도 제거합니다.

프로토콜 유형에 따른 기타 고려 사항

이러한 원칙은 프로토콜 토큰 경제 모델에 광범위하게 적용되지만, 프로토콜 유형에 따라 다른 수수료 고려 사항이 있을 수 있습니다: Layer 1 또는 Layer 2 기반의 프로토콜, 애플리케이션 체인 및 Rollup을 사용하여 구축된 프로토콜.

L1 / L2 프로토콜의 고려 사항

Layer 1 또는 Layer 2 블록체인上的 프로토콜은 스마트 계약을 체인上에 직접 배포합니다. 사용자가 프로토콜의 스마트 계약과 상호작용할 때 수수료가 부과됩니다. 이는 일반적으로 프로토콜 또는 웹사이트와 같은 사용하기 쉬운 프론트엔드를 통해 발생하며, 이 프론트엔드는 소매업체와 기본 스마트 계약 간의 인터페이스 역할을 합니다. 이 경우, 모든 수수료는 해당 프론트엔드에서 발생합니다. 위의 app.xyz 예시는 수수료 시스템이 Layer 1 프로토콜에 어떻게 적용되는지를 보여줍니다.

프로토콜은 또한 프론트엔드 수수료를 필터링하기 위해 화이트리스트 또는 블랙리스트 방식을 사용할 수 있으며, 큐레이터에게 프론트엔드 수수료를 필터링하도록 의존하지 않을 수 있습니다. 마찬가지로, 여기서의 목적은 토큰 보유자와 전체 프로토콜이 불법 활동에서 이익을 얻거나 혜택을 받지 않도록 하고, 특정 관할권의 법률 및 규정을 준수하는 것입니다. 화이트리스트 방법에서는 프로토콜이 프론트엔드에 대한 일련의 규칙을 발표하고, 규칙을 준수하는 프론트엔드를 위한 등록부를 생성하며, 선택적으로 참여하는 프론트엔드에 인증서를 발급하고, 프론트엔드가 일부 프로토콜 수수료를 얻기 위해 토큰을 스테이킹하도록 요구합니다. 만약 프론트엔드가 이러한 규칙을 준수하지 않으면, 그들은 삭감되며, 그들의 수수료 기여 인증서가 삭제됩니다.

블랙리스트 방법에서는 프로토콜이 어떤 규칙도 생성할 필요가 없지만, 프로토콜을 시작하는 프론트엔드는 허가가 필요하지 않습니다. 대신, 해당 프로토콜은 모든 프론트엔드가 해당 프론트엔드가 해당 관할권에서 규정을 준수하고 있음을 증명하는 법률 사무소의 의견을 제공하도록 요구합니다. 의견을 받은 후, 해당 프로토콜은 프론트엔드에 수수료를 지불하기 위한 인증서를 발급하며, 이 인증서는 프로토콜이 프론트엔드의 비규정 준수에 대한 통지를 받을 때만 삭제됩니다.

수수료 경로는 앞서 제공된 예시를 반영합니다. 이 두 가지 방법은 모두 분산 거버넌스의 부담을 크게 증가시켜 DAO가 규칙 세트를 설정하고 유지하거나 규정 준수에 대한 법률 의견을 평가해야 합니다. 어떤 경우에는 이것이 수용 가능할 수 있지만, 대부분의 경우 이러한 규정 준수 부담을 큐레이터에게 아웃소싱하는 것이 더 바람직합니다.

애플리케이션 체인의 고려 사항

애플리케이션 체인은 특정 프로토콜을 위한 블록체인으로, 그 검증자는 오직 해당 프로토콜에만 적용됩니다. 이들이 작업의 대가로 보상을 받습니다. Layer 1 블록체인과 달리, 검증자는 일반적으로 토큰의 통화 팽창 발행을 통해 보상을 받으며, 일부 애플리케이션 체인(dYdX)은 고객 수수료를 검증자에게 전가합니다.

이 모델에서, 토큰 보유자는 보상을 받기 위해 검증자에게 스테이킹해야 합니다. 검증자는 정교하게 설계된 스테이킹 모듈이 됩니다. 이 작업 집합은 Layer 1 검증자와 다릅니다. 애플리케이션 체인 검증자는 특정 프로토콜의 특정 거래를 정산합니다. 이러한 차이로 인해 애플리케이션 체인 검증자는 그들이 촉진하는 기본 활동에서 더 큰 법적 위험을 감수할 수 있습니다. 따라서 프로토콜은 검증자에게 자유를 부여하여 그들이 자신의 관할권의 법률 및 자신의 편안함에 따라 수행할 수 있는 작업을 수행하도록 해야 합니다. 중요한 것은, 이는 애플리케이션 체인의 무허가성을 해치지 않거나 중대한 검열 위험에 처하지 않도록 할 수 있습니다. 단, 검증자 집합이 지리적으로 분산되어 있어야 합니다.

수수료 추적 가능성의 이점을 활용하려는 애플리케이션 체인의 구조는 Layer 1 프로토콜과 유사할 것이며, 수수료 경로가 있을 때까지입니다. 그러나 검증자는 프론트엔드 매핑을 사용하여 어떤 프론트엔드에서 거래를 처리할 것인지 결정할 수 있습니다. 그런 다음, 특정 거래의 수수료는 활성 검증자 집합으로 전송되며, 참여하지 않기로 선택한 비활성 검증자는 이러한 수수료를 놓치게 됩니다. 수수료 관점에서 검증자는 위에서 언급한 스테이킹 모듈 큐레이터와 동일한 기능을 수행하며, 이러한 검증자의 스테이커는 그들이 불법 활동에서 수익을 얻지 않도록 보장할 수 있습니다. 검증자는 또한 각 관할권에서 어떤 프론트엔드가 규정 준수인지 결정하기 위해 큐레이터를 선출할 수 있습니다.

프로토콜 롤업의 고려 사항

롤업은 자체 블록 공간을 가지지만 다른 체인의 보안을 상속받을 수 있습니다. 현재 대부분의 롤업은 거래를 정렬하고 포함하는 정렬기를 가지고 있으며, 거래는 "강제 포함"이라는 과정을 통해 Layer 1에 직접 제출될 수 있습니다.

이러한 롤업이 프로토콜 특정이며 정렬기를 유일한 검증자로 두는 경우, 해당 정렬기가 포함하는 거래에서 발생하는 수수료는 선택된 규정 준수 프론트엔드 집합에 따라 또는 일반 풀로 스테이커에게 분배될 수 있습니다.

롤업이 정렬기 집합을 분산화하면, 정렬기는 사실상의 큐레이팅 스테이킹 모듈이 되며, 수수료 경로는 애플리케이션 체인의 수익 경로를 반영합니다. 정렬기는 수수료 분배를 위해 검증자를 대체하며, 각 정렬기는 어떤 프론트엔드에서 수수료를 받을 것인지 스스로 결정할 수 있습니다.

결론

프로토콜 토큰에는 많은 가능한 모델이 있지만, 정교하게 설계된 스테이킹 풀은 프로토콜 고유의 외부 도전을 해결하는 데 도움이 될 수 있습니다. 프로토콜이 직면한 내재적 및 외부적 도전을 인식함으로써, 창립자는 그들의 프로젝트를 위해 프로토콜 토큰 모델을 처음부터 더 잘 설계할 수 있습니다.