a16z: 애플리케이션 토큰이 현금 흐름을 창출하는 재무 모델을 어떻게 구축할 수 있을까?

2024.08.12

a16z: 애플리케이션 토큰이 현금 흐름을 창출하는 재무 모델을 어떻게 구축할 수 있을까?

앱 토큰의 비즈니스 모델은 그 기반 소프트웨어만큼이나 표현력이 있어야 한다.

2024.08.12 - 04:33:38

Web3 심층 보도에 집중하고 흐름을 통찰

앱 토큰의 비즈니스 모델은 그 기반 소프트웨어만큼이나 표현력이 있어야 한다.

저자: 메이슨 홀, 포터 스미스, 마일스 제닝스, 로스 슈엘

번역: TechFlow

Layer1 네트워크(또는 Layer2와 같은 컴퓨팅 스택 인접 영역)와 같은 인프라 토큰의 경우, 그 경제 모델은 이미 상당히 성숙해져 있으며 블록 공간의 수요와 공급 관계를 기반으로 하기 때문에 이해하기 쉽다. 그러나 블록체인 위에 서비스를 배포하는 스마트 계약 프로토콜로서 '분산형 비즈니스' 내에서 권리를 전달하는 앱 토큰의 경우, 여전히 경제 모델이 탐색 중이다.

앱 토큰의 비즈니스 모델은 그 하위 소프트웨어만큼이나 표현력 있어야 한다. 이를 위해 우리는 앱 토큰을 위한 현금흐름 모델을 제안한다. 이는 앱이 유연하고 개방적인 경제 모델을 구축할 수 있도록 하며, 동시에 사용자가 제공한 가치에 따라 보상을 받는 방식을 선택할 수 있게 해주는 방법이다. 이러한 접근법은 다양한 사법관할권에서의 규제 요건을 충족하면서 합법적인 활동을 통해 수익을 창출함으로써 더 큰 규제 준수를 장려한다. 또한 프로토콜이 축적하는 가치를 극대화하고, 거버넌스 최소화를 촉진한다.

여기서 설명하는 원칙들은 DeFi(탈중앙화 금융)부터 탈중앙화 소셜 앱, DePIN(탈중앙화 물리 인프라 네트워크), 그리고 기타 관련 분야까지 모든 Web3 앱에 적용된다.

토큰 모델이 직면한 도전 과제

인프라 토큰은 내재된 수요-공급 관계의 영향을 받는다. 수요가 증가하면 공급은 줄어들고 시장은 이에 따라 조정된다. 이러한 경제 기반은 특히 이더리움 개선 제안 1559(EIP-1559)를 통해 많은 인프라 토큰에서 강화되었다. EIP-1559는 모든 이더리움 트랜잭션에 대해 기본 수수료 소각 메커니즘을 도입했다. 그러나 일부 '구매 및 소각(buy and burn)' 모델의 시도가 있었음에도 불구하고, 앱 토큰은 EIP-1559에 필적할 만한 메커니즘을 갖추지 못하고 있다.

앱은 블록 공간의 사용자이며 공급자가 아니므로, 다른 사용자들이 블록 공간을 사용하면서 지불하는 가스 수수료를 수취할 수 없다. 이것이 바로 앱 토큰이 자체적인 경제 모델을 개발해야 하는 이유이다.

법적 측면에서도 문제점이 존재한다. 인프라 토큰의 경제 모델은 일반적인 블록체인 거래의 보편성과 프로그래밍된 메커니즘 덕분에 법적 리스크에 비교적 덜 취약하다. 반면 앱 토큰의 경제 모델은 규제 대상 활동을 촉진할 가능성이 있고, 거버넌스 토큰 홀더의 중개 역할을 필요로 할 수 있기 때문에 더욱 복잡하다. 미국에서는 파생상품 거래를 촉진하는 탈중앙화 거래소 운영이 엄격히 규제되는 활동이며, 이는 이더리움과 같은 프로젝트와 근본적으로 다르다.

이러한 내재적·외재적 도전 과제들은 앱 토큰이 다른 형태의 경제 모델을 필요로 함을 의미한다. 이러한 맥락에서 우리는 가능한 해결책 하나를 제시한다. 즉, 앱 토큰 홀더에게 서비스 보상을 제공하면서 프로토콜 수익을 극대화하고, 규제 준수를 유도하며, 동시에 거버넌스 최소화를 실현할 수 있는 프로토콜 설계 방법이다. 우리의 목표는 간단하다. 현금 흐름을 통해 앱 토큰에 많은 인프라 토큰들과 동등한 경제 기반을 제공하는 것이다.

우리의 해결책은 앱 토큰이 직면한 세 가지 문제 해결에 초점을 맞춘다.

거버넌스 관련 도전
가치 분배 관련 도전
규제 대상 활동 관련 도전

1. 거버넌스 관련 도전

앱 토큰은 일반적으로 거버넌스 권한을 갖고 있으며, 탈중앙화 자율조직(DAO)의 존재는 인프라 토큰이 직면하지 않는 불확실성을 초래할 수 있다. 미국에서 중요한 사업 활동을 하는 DAO의 경우, 만약 DAO가 프로토콜 수익을 통제하거나 프로토콜의 경제 활동을 중개하여 이를 프로그램화한다면 리스크가 발생할 수 있다. 이러한 리스크를 피하기 위해 프로젝트는 거버넌스 최소화를 통해 DAO의 통제력을 제거할 수 있다. 이를 달성하지 못하는 DAO의 경우, 와이오밍주에 새로 도입된 탈중앙화 비영리 협회(DUNA)는 탈중앙화된 법적 실체로서 이러한 리스크를 완화하고 적용 가능한 세법을 준수하는 데 도움이 될 수 있다.

2. 가치 분배 관련 도전

앱은 토큰 홀더에게 분배되는 가치 메커니즘을 설계할 때 신중해야 한다. 투표권과 경제적 권리를 결합하면 미국 증권법 하에서 우려를 불러일으킬 수 있으며, 특히 비례 분배나 토큰 구매 및 소각과 같은 단순하고 직접적인 메커니즘의 경우 더욱 그렇다. 이러한 메커니즘은 배당금과 주식 매입에 유사하여, 토큰이 주식과는 다른 규제 체계를 가져야 한다는 주장을 약화시킨다.

프로젝트는 이해관계자 자본주의(stakeholder capitalism)를 탐색해야 한다. 즉, 프로젝트에 기여하는 방식에 따라 토큰 홀더에게 보상을 주는 방식으로, 프로젝트에 유리한 방향으로 유도해야 한다. 많은 프로젝트들은 프론트엔드 운영(예: Liquity), 프로토콜 참여(예: Goldfinch), 또는 보안 모듈의 일환으로 담보 제공(예: Aave)과 같은 적극적인 참여를 장려한다. 여기에는 광범위한 설계 여지가 있지만, 좋은 시작점은 프로젝트 내 모든 이해관계자를 나열하고, 어떤 행동을 장려해야 할지 결정한 후, 이러한 인센티브를 통해 프로토콜이 창출할 수 있는 전체 가치를 판단하는 것이다.

간소화를 위해 본문에서는 거버넌스 참여에 대한 보상을 제공하는 단순한 보상 모델을 가정하겠지만, 다른 방안들도 존재한다.

3. 규제 대상 활동 관련 도전

규제 대상 활동을 촉진하는 앱은 토큰 홀더를 위한 가치 축적 메커니즘을 설계할 때 특히 주의해야 한다. 이러한 메커니즘이 미국 내에서 법적으로 운영되는 프론트엔드나 API를 통해 가치를 축적하지 않는다면, 토큰 홀더는 불법 활동으로부터 이득을 얻게 될 수 있다.

이 문제에 대한 대부분의 기존 제안은 활동을 미국에서 허용되는 범위로 제한하는 데 집중되어 있다. 예를 들어 특정 자산의 유동성 풀에 대해서만 프로토콜 수수료를 활성화하는 것이다. 이는 프로젝트를 가장 낮은 공통 규제 기준에 묶어두며, 글로벌 자율 소프트웨어 프로토콜의 가치 제안을 약화시킨다. 또한 거버넌스 최소화 노력을 직접적으로 약화시킨다. 어떤 수수료 전략이 유효한지를 규제 준수 관점에서 결정하는 것은 DAO의 적절한 임무가 아니다.

이상적으로는, 프로젝트가 해당 활동이 허용되는 모든 관할권에서 수수료를 징수할 수 있어야 하며, DAO가 무엇이 허용되는지 판단하는 것에 의존해서는 안 된다. 해결책은 프로토콜 수준에서의 컴플라이언스를 요구하는 것이 아니라, 프로토콜에서 생성된 수수료가 프론트엔드나 API의 출처에서만 적용 법률과 규정을 따를 경우에만 전달되도록 보장하는 것이다. 미국이 어떤 앱이 촉진하는 거래에 대해 수수료 징수를 불법화한다면, 세계 다른 지역에서 해당 활동이 완전히 합법적이더라도 해당 앱의 토큰 경제 가치가 제로로 떨어질 수 있다. 수수료 축적과 분배의 유연성은 궁극적으로 규제 압박에 대한 회복력을 의미한다.

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

부적절한 프론트엔드로부터 발생하는 잠재적 리스크를 해결하려면 수수료의 추적 가능성이 중요하다. 동시에 검열 리스크를 도입하거나 프로토콜을 허가형으로 만들지 않아야 한다. 추적 가능성을 통해 앱은 토큰 홀더에게 누적되는 수수료가 오직 토큰 홀더의 관할권 내에서 합법적인 프론트엔드에서만 발생하도록 보장할 수 있다. 수수료를 추적할 수 없다면, 토큰 홀더를 부적절한 프론트엔드(즉, 규제 미준수 프론트엔드가 징수한 수수료)로부터 누적된 가치와 격리할 수 없으며, 이는 토큰 홀더에게 리스크를 초래할 수 있다.

수수료를 추적 가능하게 하기 위해 프로토콜은 두 단계로 구성된 앱 토큰 스테이킹 시스템 설계를 채택할 수 있다.

첫 번째 단계: 수수료 출처 프론트엔드 식별
두 번째 단계: 커스텀 로직에 따라 수수료를 다양한 풀로 라우팅

프론트엔드 매핑

수수료의 추적 가능성은 도메인명에서 공개키/비밀키 쌍으로의 매핑을 필요로 한다. 이러한 매핑이 없다면 악의적인 프론트엔드가 거래를 위조하여 마치 정직한 도메인에서 제출된 것처럼 위장할 수 있다. 암호학은 우리가 프론트엔드를 "등록(register)"할 수 있게 하며, 도메인명과 공개키의 매핑을 영구적으로 기록하고, 해당 도메인이 실제로 공개키를 제어함을 증명하며, 비밀키로 거래에 서명할 수 있게 한다. 이를 통해 우리는 거래(따라서 수수료 포함)를 특정 도메인에 귀속시킬 수 있다.

수수료 라우팅

수수료 출처가 추적 가능해지면, 프로토콜은 이러한 수수료를 어떻게 분배할지 결정할 수 있으며, 이는 불법 거래로부터 발생하는 수수료로부터 토큰 홀더를 보호하면서도 DAO의 탈중앙화된 거버넌스 부담을 늘리지 않는다. 이를 설명하기 위해, 각 프론트엔드마다 별도의 스테이킹 풀을 두는 설계에서부터 모든 프론트엔드가 하나의 풀을 공유하는 설계까지, 앱 토큰 스테이킹 설계 범위를 고려할 수 있다.

가장 단순한 구조에서 각 프론트엔드의 수수료는 독립된 특정 프론트엔드 전용 스테이킹 모듈로 라우팅될 수 있다. 어떤 프론트엔드에 스테이킹할지 선택함으로써, 토큰 홀더는 자신이 어떤 수수료를 받을지 결정하고, 법적 리스크를 초래할 수 있는 수수료는 피할 수 있다. 예를 들어, 토큰 홀더는 유럽에서 모든 규제 승인을 받은 프론트엔드와 연결된 모듈에만 스테이킹할 수 있다. 이 설계는 단순해 보이지만 실제로는 매우 복잡하다. 50개의 서로 다른 프론트엔드에 대해 50개의 스테이킹 풀이 생길 수 있으며, 수수료 분산은 토큰 가치에 부정적인 영향을 줄 수 있다.

설계 범위의 반대쪽 끝에서는 각 프론트엔드의 수수료가 모두 모일 수 있다. 그러나 이것은 수수료 추적 가능성의 목적을 무너뜨린다. 모든 수수료가 합쳐진다면, 규제를 준수하는 프론트엔드와 비준수 프론트엔드의 수수료를 구분할 수 없으며, 한 개의 '썩은 사과'가 통째로 물든다. 토큰 홀더는 아무런 수수료도 받지 않거나, 모든 풀에 스테이킹하는 선택 사이에서 결정해야 한다. 후자의 경우, 그들은 관할권 내에서 비준수 프론트엔드의 불법 활동으로부터 이득을 얻게 되며, 이 옵션은 많은 토큰 홀더가 참여하기를 꺼리게 하거나 현재의 차선책인 DAO가 수수료 적용 가능 지역을 평가해야 하는 설계로 돌아가게 할 수 있다.

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

이러한 복잡성은 큐레이션(curation)을 통해 해결할 수 있다. 누구나 프론트엔드를 만들 수 있고, 각 프론트엔드가 자체 스테이킹 모듈을 가질 수 있는 권한 없는 스마트 계약 프로토콜 앱을 상상해보자. 이 프로토콜의 프론트엔드 하나를 App.xyz라고 하자.

App.xyz는 자신의 사법관할권 내 특정 규제 준수 규칙을 따를 수 있다. App.xyz에서 발생하는 앱 활동은 프로토콜 수수료를 생성한다. App.xyz는 자체 스테이킹 모듈을 가지며, 토큰 홀더는 해당 모듈에 직접 토큰을 스테이킹하거나, 자신이 규제 준수라고 판단하는 프론트엔드 바구니를 개별적으로 선별하려는 큐레이터에게 스테이킹할 수 있다. 이러한 스테이커들은 스테이킹한 프론트엔드가 생성한 수수료 형태로 수익을 얻게 된다. 만약 어떤 프론트엔드가 100달러의 수수료를 발생시키고, 100개의 실체가 각각 1개의 토큰을 스테이킹했다면, 각 실체는 1달러의 수익을 주장할 수 있다. 큐레이터는 초기에 서비스에 대한 수수료를 받을 수 있다. 미래에는 정부가 관할권 내 프론트엔드의 규제 준수 여부를 체인 상에서 인증함으로써 소비자를 보호하고 자동화된 큐레이션의 추가 혜택을 실현할 수 있다.

이 모델의 잠재적 리스크는 비준수 프론트엔드의 운영 비용이 더 낮을 수 있다는 점이다. 이들은 규제 준수 프론트엔드보다 관리 비용이 없기 때문이다. 또한 트레이더에게 프론트엔드 수수료를 되돌려주는 모델을 설계하여 변칙적 접근을 더욱 유도할 수도 있다. 이 리스크는 두 가지 요인으로 완화될 수 있다. 첫째, 대부분의 사용자는 실제로 현지 법률과 규정을 따르는 규제 준수 프론트엔드를 원하며, 특히 대규모 규제 대상 기관일수록 더욱 그렇다. 둘째, 거버넌스는 마지막 수단 또는 '거부권(veto power)'으로서, 반복적으로 규칙을 위반하고 앱의 생존 가능성을 위협하는 비준수 프론트엔드에 대해 악행을 억제하는 데 중요한 역할을 할 수 있다.

마지막으로, 등록된 프론트엔드를 통해 시작되지 않은 모든 거래의 수수료는 단일 통합 스테이킹 모듈에 저장되어, 프로토콜이 봇과 기타 프로토콜 스마트 계약과 직접 상호작용하는 거래로부터 수익을 포착할 수 있도록 한다.

이론에서 실행으로: 방법을 현실에 적용

앱 토큰 스택을 좀 더 자세히 살펴보자. 프론트엔드 스테이킹을 촉진하기 위해 프로토콜은 프론트엔드가 등록해야 하는 등록 스마트 계약을 설정해야 한다.

각 프론트엔드나 API는 ENS DNS 통합처럼 도메인의 DNS 레코드에 특별한 TXT 레코드를 추가할 수 있다. 이 TXT 레코드는 프론트엔드가 생성한 키 쌍 중 공개키를 포함하며, 이를 인증서라고 부른다.

프론트엔드 클라이언트는 register() 함수를 호출하고 자신의 도메인을 소유하고 있음을 입증할 수 있다. 도메인과 인증서 공개키의 매핑 및 역방향 매핑이 저장된다.
클라이언트가 거래를 생성할 때, 거래 페이로드에 인증서 공개키로 서명한다. 이 정보는 패키징되어 앱의 스마트 계약으로 전달된다.
앱의 스마트 계약은 인증서를 검증하고, 올바른 거래 주체인지, 등록되었는지 확인한다. 검증되면 거래가 처리된다. 거래로 발생한 수수료는 등록부에서 가져온 도메인과 함께 FeeCollector 계약으로 전송된다.
FeeCollector는 큐레이터, 사용자, 검증자 등이 특정 도메인 또는 도메인 그룹에 직접 토큰을 스테이킹할 수 있도록 한다. 이러한 계약은 각 도메인의 스테이킹 토큰 수량, 각 주소의 지분, 스테이킹 시간을 추적해야 한다. 인기 있는 유동성 채굴 구현이 이 계약 로직의 시작점이 될 수 있다. 큐레이터에게 스테이킹한 사용자(또는 직접 FeeCollector 계약에 스테이킹한 사용자)는 해당 도메인에 스테이킹된 앱 토큰 수량에 따라 수수료 지분을 인출할 수 있다. 이 아키텍처는 MetaMorpho/Morpho Blue와 유사할 수 있다.

이 방안은 앱 DAO의 거버넌스 부담을 증가시키지 않고 도입될 수 있다. 오히려 거버넌스 책임이 줄어들 수 있는데, 수수료 스위치가 모든 프로토콜 거래에 대해 영구적으로 켜져 있어, DAO가 프로토콜 경제 모델을 통제하는 것을 완전히 제거할 수 있기 때문이다.

앱 유형에 따른 추가 고려사항

이러한 원칙들은 앱 토큰 경제 모델 전반에 걸쳐 광범위하게 적용되지만, 앱 유형(Layer1 또는 Layer2 위에 구축된 앱, 앱 체인, 롤업 기반 앱 등)에 따라 추가적인 수수료 고려사항이 있을 수 있다.

L1/L2 앱 고려사항

Layer1 또는 Layer2 블록체인 위의 앱은 스마트 계약을 체인 상에 직접 배포한다. 사용자가 앱의 스마트 계약과 상호작용할 때 수수료가 부과된다. 일반적으로 이러한 상호작용은 사용자 친화적인 프론트엔드(웹사이트 또는 앱)를 통해 이루어지며, 이 프론트엔드는 일반 사용자와 저층 스마트 계약 사이의 인터페이스 역할을 한다. 이 경우 수수료는 모두 해당 프론트엔드에서 기인한다. 앞서 언급한 app.xyz 예시는 Layer1 앱에서 수수료 시스템이 어떻게 작동하는지를 설명한다.

앱은 큐레이터에 의존하는 대신 프론트엔드 수수료를 필터링하기 위해 화이트리스트 또는 블랙리스트 접근법을 채택할 수도 있다. 여기서 목적은 토큰 홀더와 전체 프로토콜이 불법 활동에서 이익을 얻거나 혜택을 받지 않도록 하고, 특정 사법관할권의 법률 및 규정을 따르는 것이다.

화이트리스트 방식에서는, 앱이 프론트엔드 규칙 세트를 발행하고, 이 규칙을 따르는 프론트엔드의 등록부를 만들며, 참가를 원하는 프론트엔드에 인증서를 발급하고, 프론트엔드가 앱 수수료의 일부를 받기 위해 토큰을 스테이킹하도록 요구한다. 프론트엔드가 이 규칙을 따르지 않으면 수수료 기여 자격이 박탈되고 인증서가 취소된다.

블랙리스트 방식에서는, 앱이 별도의 규칙을 만들 필요는 없지만, 앱용 프론트엔드 시작 과정이 무허가(unpermissioned)가 아니다. 대신 앱은 모든 프론트엔드가 활성화되기 전에 해당 관할권의 규정을 준수한다는 법무법인의 의견서를 제출하도록 요구한다. 의견서를 받으면 앱은 프론트엔드에 수수료 기여 인증서를 발급하며, 규제기관이 해당 프론트엔드가 비준수임을 통보하기 전까지는 인증서가 취소되지 않는다.

수수료 파이프라인은 앞서 설명한 예시와 유사하게 작동한다.

이 두 접근법 모두 탈중앙화 거버넌스 부담을 크게 증가시킨다. DAO가 일련의 규칙을 수립하고 유지하거나, 규제 준수 여부에 대한 법적 의견을 평가해야 하기 때문이다. 일부 경우에는 이럴 수 있지만, 대부분의 경우 규제 부담을 큐레이터에게 외주하는 것이 더 바람직하다.

앱 체인 고려사항

앱 체인은 특정 앱을 위해 설계된 블록체인으로, 검증자들이 해당 앱 전용으로 작업한다.

이들의 작업에 대한 보상으로 검증자들은 수익을 얻는다. 일반적인 Layer1 블록체인의 검증자들이 인플레이션성 토큰 발행을 통해 보상받는 것과 달리, 일부 앱 체인(dYdX 등)은 고객 수수료를 검증자에게 전달한다.

이 모델에서 토큰 홀더는 보상을 받기 위해 검증자에게 스테이킹해야 한다. 검증자는 큐레이팅된 스테이킹 모듈이 된다.

이 작업 집합은 Layer1 검증자와 다르다. 앱 체인 검증자는 특정 앱의 특정 거래만 처리한다. 이러한 차이로 인해 앱 체인 검증자는 촉진하는 활동의 성격상 더 큰 법적 리스크를 감수할 수 있다. 따라서 프로토콜은 검증자가 자신의 관할권 법률과 개인적 편의에 따라 자유롭게 작업을 수행할 수 있도록 해야 한다. 중요한 점은, 검증자의 지리적 분산이 잘 이루어진다면, 앱 체인의 무허가성이나 중대한 검열 리스크를 위태롭게 하지 않고도 이를 달성할 수 있다는 것이다.

수수료 추적 가능성의 이점을 활용하려는 앱 체인 아키텍처는 수수료 파이프라인까지 Layer1 앱과 유사하다. 하지만 검증자는 프론트엔드 매핑을 사용하여 처리하고자 하는 프론트엔드를 결정할 수 있다. 특정 거래의 수수료는 활성 검증자 집합에 분배되며, 참여를 선택하지 않은 비활성 검증자는 이러한 수수료를 놓친다. 수수료 측면에서 검증자는 앞서 논의한 스테이킹 모듈 큐레이터와 동일한 기능을 하며, 이 검증자들에게 스테이킹한 스테이커는 불법 활동에서 수익을 얻지 않도록 보장할 수 있다. 검증자는 또한 큐레이터를 선택하여 각자의 관할권 내에서 어떤 프론트엔드가 규제를 준수하는지 결정할 수 있다.