위험 경고: '가상화폐', '블록체인'이라는 이름으로 불법 자금 모집 위험에 주의하세요. — 은행보험감독관리위원회 등 5개 부처
검색
로그인
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt
BTC
ETH
HTX
SOL
BNB
시장 동향 보기

a16z: 프로토콜 토큰은 어떻게 현금 흐름을 생성합니까?

Foresight News
特邀专栏作者
2024-08-09 12:00
이 기사는 약 5522자로, 전체를 읽는 데 약 8분이 소요됩니다
프로토콜 토큰을 위한 새로운 금융 모델: 현금 흐름을 생성하는 방법은 무엇입니까?

원저자: a16z Crypto

원본 편집: Pzai, Foresight News

네트워크의 레이어 1(또는 레이어 2와 같은 컴퓨팅 스택의 인접 부분)에 해당하는 인프라 토큰의 경우 경제 모델은 이미 잘 개발되고 이해되었으며 블록 공간의 공급과 수요에 뿌리를 두고 있습니다. 그러나 블록체인에 서비스를 배포하고 "분산 비즈니스"에서 권리를 상속하는 스마트 계약 프로토콜인 프로토콜 토큰(앱 토큰)의 경우 경제 모델 구축이 여전히 연구되고 있습니다.

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

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

토큰 모델이 직면한 과제

인프라 토큰은 본질적인 공급과 수요의 영향을 받습니다. 수요가 증가하면 공급이 감소하고 시장은 그에 따라 조정됩니다. EIP-1559는 모든 이더리움 거래에 대한 기본 수수료 소각을 구현하는 제안을 통해 많은 인프라 토큰의 기본 경제 기반을 가속화합니다. 그러나 산발적인 모델 구매 및 소각 시도에도 불구하고 프로토콜 토큰에 대해 EIP-1559와 동등한 시도는 없었습니다.

프로토콜은 제공자가 아닌 블록 공간의 사용자이므로 자신의 블록 공간을 사용하는 다른 사람의 가스 요금에 의존할 수 없습니다. 그렇기 때문에 그들은 그들만의 경제 모델을 개발해야 합니다.

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

이러한 내재적 과제와 외재적 과제의 조합은 프로토콜 토큰에 다른 경제 모델이 필요하다는 것을 의미합니다. 이를 염두에 두고 우리는 프로토콜 수익을 극대화하고, 규제 준수를 장려하며, 거버넌스 최소화를 통합하는 동시에 프로토콜 토큰 보유자에게 혜택을 제공하는 프로토콜 설계에 대한 접근 방식을 제안합니다. 서비스에 대한 보상이 제공됩니다. 우리의 목표는 간단합니다. 많은 인프라 토큰이 이미 보유하고 있는 현금 흐름을 통해 동일한 경제적 기반을 프로토콜 토큰에 제공하는 것입니다.

우리의 솔루션은 거버넌스 문제, 가치 분배 문제 및 규정 준수 활동 문제와 관련하여 프로토콜 토큰이 직면한 세 가지 문제를 해결하는 데 중점을 둡니다.

거버넌스 과제

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

가치분배의 도전

프로토콜은 또한 토큰 보유자에게 가치를 할당하기 위한 메커니즘을 설계할 때 주의를 기울여야 합니다. 의결권과 경제적 권리를 결합하는 것은 미국 증권법에 따라 우려를 불러일으킬 수 있으며, 특히 비례 배분, 토큰 구매 및 폐기와 같은 간단하고 직접적인 메커니즘의 경우 더욱 그렇습니다. 이러한 메커니즘은 배당금 및 자사주 매입과 유사해 보이며 토큰이 주식과 다른 규제 프레임워크를 받아야 한다는 주장을 약화시킬 수 있습니다.

대신, 프로젝트는 이해관계자 자본주의를 탐구하여 프로젝트에 이익이 되는 방식으로 프로젝트에 대한 기여에 대해 토큰 보유자에게 보상해야 합니다. 많은 프로젝트에서는 프런트엔드 운영(Liquity), 프로토콜 참여(Goldfinch), 보안 모듈의 일부로 담보 제공(Aave) 등 포지티브 섬 참여를 장려합니다. 여기의 디자인 공간은 열려 있지만 좋은 출발점은 프로젝트의 모든 이해관계자를 계획하고, 각 이해관계자의 어떤 행동을 장려해야 하는지 결정하고, 프로토콜이 이 인센티브를 통해 창출할 수 있는 전반적인 가치를 결정하는 것입니다.

단순화를 위해 이 기사에서는 다른 계획이 존재하더라도 거버넌스 참여에 대해 토큰 보유자에게 보상하는 간단한 보상 모델을 가정합니다.

규정 준수 활동 과제

규정 준수 활동을 촉진하는 프로토콜은 토큰 보유자를 위한 가치 축적 메커니즘을 설계할 때에도 주의해야 합니다. 그러한 메커니즘이 해당 법률을 준수하지 않는 프런트 엔드 또는 API에서 가치를 생성하는 경우 토큰 보유자는 불법 활동으로 이익을 얻을 수 있습니다.

이 문제에 대해 제안된 대부분의 솔루션은 미국에서 허용되는 활동으로 인한 가치 축적을 제한하는 데 중점을 두고 있습니다. 예를 들어 특정 자산과 관련된 유동성 풀에 대해서만 프로토콜 수수료를 부과하는 것입니다. 이는 규제 접근 방식의 가장 낮은 공통 분모를 대상으로 하며 글로벌 자율 소프트웨어 프로토콜의 가치 제안을 약화시킵니다. 이는 또한 거버넌스 최소화 노력을 직접적으로 약화시킵니다. 규제 준수 관점에서 볼 때 어떤 과금 전략이 효과적인지 결정하는 것은 DAO에 적합한 작업이 아닙니다.

이상적인 세계에서 프로젝트는 허용되는 활동을 결정하기 위해 DAO에 의존할 필요 없이 활동을 허용하는 모든 관할 구역의 활동에서 수수료를 징수할 수 있습니다. 프로토콜 수준에서 규정 준수를 요구하는 대신, 수수료를 발생시킨 프런트엔드 또는 API가 프런트엔드 위치의 해당 법률 및 규정을 준수하는 경우에만 프로토콜에서 발생하는 수수료가 전달되도록 하는 것이 해결책입니다. 미국이 프로토콜에 의해 촉진되는 특정 유형의 거래에 대해 수수료를 부과하는 것을 불법으로 규정한 경우, 해당 활동이 전 세계 다른 모든 국가에서 완벽하게 허용되더라도 프로토콜 토큰의 경제적 가치가 0으로 줄어들 수 있습니다. 수수료 발생 및 할당의 유연성은 궁극적으로 규제 압력에 대한 탄력성과 동일합니다.

핵심 문제: 비용 추적성

수수료 추적성은 검토 위험을 초래하거나 프로토콜 라이선스를 무효화하지 않고 프런트 엔드의 비준수로 인해 발생하는 잠재적 위험을 해결하는 데 중요합니다. 추적성을 통해 프로토콜은 토큰 보유자에게 발생하는 모든 수수료가 토큰 보유자가 위치한 관할권의 합법적이고 규정을 준수하는 프런트 엔드에서만 발생하도록 보장합니다. 수수료를 추적할 수 없는 경우 토큰 보유자는 비준수 프런트엔드에서 가치를 창출할 수 없으며(즉, 비준수 프런트엔드에 의해 부과되는 수수료) 토큰 보유자를 위험에 빠뜨릴 수 있습니다.

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

  • 1단계: 비용이 발생하는 프런트 엔드 결정

  • 2단계: 맞춤형 로직을 기반으로 수수료를 다른 풀로 라우팅

매핑 프런트엔드

수수료 추적을 위해서는 도메인에서 공개/개인 키 쌍으로의 일대일 매핑이 필요합니다. 이러한 매핑이 없으면 악의적인 프런트엔드가 거래를 스푸핑하고 거래가 정직한 도메인에서 제출된 것처럼 가장할 수 있습니다. 암호화를 사용하면 프런트엔드를 "등록"하고, 도메인과 공개 키의 매핑을 불변하게 기록하고, 도메인이 실제로 해당 공개 키를 제어한다는 것을 증명하고, 해당 개인 키를 사용하여 트랜잭션에 서명할 수 있습니다. 이를 통해 거래를 특정 도메인에 귀속시켜 요금을 청구할 수 있습니다.

경로 비용

수수료의 출처를 추적할 수 있게 되면 프로토콜은 불법 거래 수수료로부터 토큰 보유자를 보호하면서도 DAO의 분산 거버넌스 부담을 증가시키지 않는 방식으로 이러한 수수료를 분배하는 방법을 결정할 수 있습니다. 이를 설명하는 데 도움이 되도록 프런트엔드당 하나의 스테이킹 풀부터 모든 프런트엔드에 대해 하나의 스테이킹 풀까지 프로토콜 토큰 스테이킹에 대해 가능한 설계 범위를 고려하십시오.

가장 간단한 구조에서 각 프런트엔드의 수수료는 별도의 프런트엔드별 스테이킹 모듈로 라우팅될 수 있습니다. 스테이크할 프런트엔드를 선택함으로써 토큰 보유자는 자신이 받을 수수료를 결정하고 토큰 보유자를 법적 위험에 빠뜨릴 수 있는 수수료를 피할 수 있습니다. 예를 들어, 토큰 보유자는 유럽의 모든 규제 승인을 받은 프런트엔드와 관련된 모듈만 스테이킹할 수 있습니다. 이 디자인은 단순해 보이지만 실제로는 상당히 복잡합니다. 50개의 서로 다른 프런트엔드에 잠재적으로 50개의 스테이킹 풀이 있으므로 수수료 희석은 토큰 가치에 부정적인 영향을 미칠 수 있습니다.

반면, 각 프런트 엔드의 수수료를 함께 모을 수 있지만 이는 수수료 추적의 목적을 상실합니다. 모든 비용을 하나로 묶으면 규정을 준수하는 프런트 엔드 비용과 규정을 준수하지 않는 프런트 엔드 비용을 구별할 방법이 없습니다. 쥐똥 하나가 전체 비용을 망칠 수 있습니다. 토큰 보유자는 수수료를 부과하지 않거나 해당 관할 구역의 비준수 프런트엔드에 의한 불법 활동으로 인해 이익을 얻을 수 있는 풀의 지분을 보유하는 것 중에서 선택해야 합니다. 이 옵션은 많은 토큰 보유자가 참여하는 것을 막거나 시스템을 되돌릴 수 있습니다. DAO는 수수료를 징수할 수 있는 곳을 평가해야 하는 현재 차선책 설계로 전환합니다.

큐레이션을 통한 비용 추적성 문제 해결

이러한 복잡성은 큐레이션을 통해 해결될 수 있습니다. 수수료와 토큰이 있는 무허가형 스마트 계약 프로토콜을 생각해 보세요. 누구나 프로토콜에 대한 프런트엔드를 만들 수 있으며 모든 프런트엔드는 자체 스테이킹 모듈을 가질 수 있습니다. 우리는 이 프로토콜의 프런트 엔드를 app.xyz라고 부릅니다.

App.xyz는 운영되는 관할권의 특정 규정 준수 규칙을 준수할 수 있습니다. app.xyz에서 시작되는 프로토콜 활동에는 프로토콜 수수료가 발생합니다. App.xyz에는 토큰 보유자가 토큰을 직접 스테이킹하거나 준수하는 것으로 간주되는 프런트엔드 바구니를 개별적으로 선택하려는 큐레이터에게 토큰을 스테이킹할 수 있는 자체 스테이킹 모듈이 있습니다. 이러한 토큰 스테이커는 자신이 스테이킹한 프런트엔드 세트에서 수수료 형태로 수익을 얻습니다. 프런트 엔드가 $100의 수수료를 생성하고 100개의 개체가 각각 1개의 토큰을 보유하는 경우 각 개체는 $1를 받을 자격이 있습니다. 큐레이터는 처음에 서비스에 대한 요금을 청구할 수 있습니다. 앞으로 정부는 큐레이션 자동화의 부수적인 이점과 함께 소비자를 보호하기 위해 관할권 내에서 프런트엔드 규정 준수를 입증하기 위해 온체인 증명을 수행할 수 있습니다.

이 모델의 잠재적인 위험 중 하나는 비준수 프런트 엔드에는 준수 프런트 엔드의 관리 오버헤드가 부족하기 때문에 운영 비용이 더 낮을 수 있다는 것입니다. 또한 솔루션에 대한 인센티브를 더욱 강화하기 위해 거래자에게 프런트엔드 수수료를 회수하는 모델을 설계할 수도 있습니다. 두 가지 요소가 이러한 위험을 줄입니다. 첫째, 대부분의 사용자는 실제로 현지 법률 및 규정을 준수하는 규정을 준수하는 프런트 엔드를 원하며 이는 특히 대규모 규제 기관에 적용됩니다. 둘째, 반복적으로 규칙을 위반하고 프로토콜의 실행 가능성을 위태롭게 하는 비준수 프런트 엔드의 경우 거버넌스는 나쁜 행동을 억제하기 위한 최후의 수단 또는 "거부권"으로서 중요한 역할을 할 수 있습니다.

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

이론에서 구현까지: 방법을 실제로 적용

프로토콜 토큰 스택에 대해 더 자세히 살펴보겠습니다. 프런트엔드 스테이킹을 용이하게 하는 프로토콜의 경우 프런트엔드가 등록해야 하는 레지스트리 스마트 계약의 설정이 필요합니다.

  • 각 프런트 엔드 또는 API는 ENS DNS 통합과 같은 도메인의 DNS 레코드에 특수 TXT 레코드를 추가할 수 있습니다. 이 TXT 레코드에는 인증서라고 하는 프런트 엔드에서 한 번 생성된 키 쌍의 공개 키가 포함되어 있습니다.

  • 그런 다음 프런트 엔드 클라이언트는 등록 기능을 호출하고 도메인 이름을 소유하고 있음을 증명하여 도메인과 인증서 공개 키 매핑을 저장하며 그 반대의 경우도 마찬가지입니다.

  • 클라이언트를 통해 트랜잭션이 생성되면 인증서 공개 키를 사용하여 트랜잭션 페이로드에도 서명합니다. 이는 번들 형태로 프로토콜의 스마트 계약에 전달됩니다.

  • 프로토콜의 스마트 계약은 인증서를 확인하여 해당 인증서가 올바른 거래 주체(프런트엔드)에 해당하고 등록되었는지 확인합니다. 그렇다면 거래를 처리하세요. 거래로 인해 생성된 수수료는 도메인 이름과 함께 (레지스트리에서) FeeCollector 계약으로 전송됩니다.

  • FeeCollector 계약을 통해 큐레이터, 사용자, 검증자 및 기타 사람들은 토큰을 도메인 또는 도메인 집합에 직접 스테이킹할 수 있습니다. 이러한 계약은 각 도메인에 스테이킹된 토큰 수, 각 주소의 해당 지분 지분 및 스테이킹된 시간을 추적해야 합니다. 유동성 채굴의 일반적인 구현은 이 계약 논리의 출발점이 될 수 있습니다.

  • 큐레이터(또는 직접 수수료 관리 계약 자체)에 스테이킹한 사용자는 도메인에 스테이킹된 프로토콜 토큰의 양을 기준으로 비례 배분된 수수료를 인출할 수 있습니다. 아키텍처는 MetaMorpho/Morpho Blue와 유사할 수 있습니다.

이 메커니즘은 프로토콜 DAO의 거버넌스 부담을 늘리지 않고도 도입될 수 있습니다. 실제로, 프로토콜에 의해 촉진되는 모든 거래에 대해 수수료 스위치를 영구적으로 켤 수 있으므로 거버넌스 책임이 줄어들 수 있으며, 이를 통해 프로토콜의 경제 모델에 대한 DAO의 통제권이 제거됩니다.

프로토콜 유형에 따른 추가 고려 사항

이러한 원칙은 프로토콜 토큰 경제 모델에 광범위하게 적용되지만 프로토콜 유형(계층 1 또는 계층 2에 구축된 프로토콜, 애플리케이션 체인, 롤업을 사용하여 구축된 프로토콜)에 따라 추가 수수료 고려 사항이 있을 수 있습니다.

L1/L2 프로토콜에 대한 고려 사항

레이어 1 또는 레이어 2 블록체인의 프로토콜은 스마트 계약을 체인에 직접 배포합니다. 사용자가 프로토콜의 스마트 계약과 상호 작용할 때 수수료가 부과됩니다. 이는 일반적으로 소매 투자자와 기본 스마트 계약 간의 인터페이스 역할을 하는 사용하기 쉬운 프런트 엔드(예: 프로토콜 또는 웹 사이트)를 통해 발생합니다. 이 경우 모든 요금은 해당 프런트 엔드에서 발생합니다. app.xyz에 대한 위의 예는 레이어 1 프로토콜에서 과금 시스템이 작동하는 방식을 보여줍니다.

프로토콜은 또한 프런트엔드 수수료를 필터링하기 위해 큐레이터에 의존하는 대신 화이트리스트 또는 블랙리스트를 사용하여 프런트엔드 수수료를 필터링할 수 있습니다. 여기서도 목적은 토큰 보유자와 전체 프로토콜이 불법 활동으로 인해 이익을 얻지 않도록 하고 특정 관할권의 법률 및 규정을 준수하도록 하는 것입니다. 화이트리스트 접근 방식에서 프로토콜은 프런트엔드에 대한 일련의 규칙을 게시하고, 규칙을 따르는 프런트엔드에 대한 레지스트리를 생성하고, 동의한 프런트엔드에 인증서를 발급하고, 프런트엔드가 프로토콜 수수료의 일부를 받기 위해 토큰을 스테이킹하도록 요구합니다. . 프런트 엔드가 이러한 규칙을 준수하지 않는 경우 해당 프런트 엔드는 중단되고 수수료 기여 인증서가 제거됩니다.

블랙리스트 접근 방식에서는 프로토콜이 규칙을 만들 필요가 없지만 프로토콜을 실행하는 프런트엔드는 승인되지 않습니다. 대신, 계약은 프런트 엔드가 계약을 사용하도록 허용하기 전에 프런트 엔드가 해당 관할권을 준수함을 인증하는 법률 회사의 의견을 제공하도록 모든 프런트 엔드를 요구합니다. 의견이 접수되면 프로토콜은 수수료 지불을 위해 프런트엔드에 인증서를 발급합니다. 이 인증서는 프로토콜이 규제 기관으로부터 프런트엔드의 비준수에 대한 알림을 받은 경우에만 제거됩니다.

비용 채널은 이전 섹션에 제공된 예를 반영합니다. 두 접근 방식 모두 분산형 거버넌스의 부담을 크게 증가시켜 DAO가 일련의 규칙을 수립 및 유지하거나 규정 준수에 관한 법적 조언을 평가하도록 요구합니다. 어떤 경우에는 이것이 허용될 수 있지만 대부분의 경우 이러한 규정 준수 부담을 큐레이터에게 아웃소싱하는 것이 바람직합니다.

애플리케이션 체인에 대해 참고할 사항

애플리케이션 체인은 특정 프로토콜에 대한 블록체인이며 해당 유효성 검사기는 해당 프로토콜에만 적용됩니다. 이러한 검증인은 작업에 대한 대가로 보상을 받습니다. 검증인이 일반적으로 토큰의 인플레이션 발행을 통해 보상을 받는 레이어 1 블록체인과 달리 일부 애플리케이션 체인(dYdX)은 고객 수수료를 검증인에게 전달합니다.

이 모델에서 토큰 보유자는 보상을 받기 위해 검증인에게 스테이킹해야 합니다. 검증인은 조직화된 스테이킹 모듈이 됩니다. 이 작업 세트는 레이어 1 유효성 검사기와 다릅니다. 애플리케이션 체인 유효성 검사기는 특정 프로토콜의 특정 트랜잭션을 해결합니다. 이러한 차이로 인해 Lisk 검증인은 자신이 촉진하는 기본 활동에서 더 큰 법적 위험을 부담할 수 있습니다. 따라서 프로토콜은 검증인에게 관할권의 법률과 편안한 수준에 따라 수행할 수 있는 자유를 제공해야 합니다. 중요한 것은 검증자 세트가 지리적으로 분산되어 있는 경우 애플리케이션 체인의 무허가 특성을 위험에 빠뜨리거나 심각한 검열 위험에 노출시키지 않고 이를 수행할 수 있다는 것입니다.

수수료 추적성을 활용하려는 애플리케이션 체인의 아키텍처는 수수료 채널이 있을 때까지 레이어 1 프로토콜과 유사합니다. 그러나 검증인은 프런트엔드 매핑을 사용하여 트랜잭션을 처리할 프런트엔드를 결정할 수 있습니다. 특정 거래에 대한 수수료는 활성 검증인에게 전달되며, 참여하지 않기로 선택한 비활성 검증인은 해당 수수료를 잃게 됩니다. 수수료 측면에서 검증인은 위에서 언급한 스테이킹 모듈 큐레이터와 동일한 기능을 수행하며, 이러한 검증인의 스테이커는 불법 활동으로 인해 수입을 얻지 않도록 할 수 있습니다. 검증인은 큐레이터를 선출하여 각 관할권에서 어떤 프런트엔드가 규정을 준수하는지 결정할 수도 있습니다.

프로토콜 롤업에 대한 참고 사항

롤업에는 자체 블록 공간이 있지만 다른 체인의 보안을 상속받을 수 있습니다. 오늘날 대부분의 롤업에는 트랜잭션 정렬 및 포함을 담당하는 시퀀서가 있지만 트랜잭션은 "강제 포함"이라는 프로세스를 통해 레이어 1에 직접 커밋될 수 있습니다.

이러한 롤업이 프로토콜에 따라 다르고 주문자가 유일한 검증인인 경우 해당 주문자에 포함된 거래에서 생성된 수수료는 큐레이트된 규정 준수 프런트엔드 세트 또는 일반 풀을 기반으로 스테이커에게 배포될 수 있습니다.

Rollup이 시퀀서 세트를 분산화한다면 시퀀서는 사실상 엄선된 스테이킹 모듈이 될 것이며 수수료 채널은 Appchain의 수익 채널을 반영하게 될 것입니다. 주문자는 수수료 분배를 위해 검증자를 교체하며, 각 주문자는 수수료를 받을 프런트엔드를 스스로 결정할 수 있습니다.

요약

프로토콜 토큰에 대한 가능한 모델은 많지만 스테이킹 풀은 신중하게 선별되면 프로토콜별 외부 문제를 해결하는 데 도움이 될 수 있습니다. 프로토콜이 직면하는 내재적 및 외부적 과제를 인식함으로써 창립자는 처음부터 프로젝트에 대한 프로토콜 토큰 모델을 더 잘 설계할 수 있습니다.

감사의 말: 이 프로젝트를 시작한 Porter Smith 에게 감사드립니다.


a16z
Odaily 공식 커뮤니티에 가입하세요