• 인프라 토큰 - 레이어 1 네트워크(또는 레이어 2와 같은 계산 스택의 인접 부분)에 해당합니다. -- 경제 모델이 잘 발달되어 있고 널리 이해되고 있으며 블록 공간에 대한 수요와 공급을 기반으로 합니다. 그러나 "분산 비즈니스"에서 권리를 전달하는 블록체인 위에 서비스를 배포하기 위한 스마트 콘트랙트 프로토콜인 애플리케이션 토큰의 경우 경제 모델은 여전히 연구 중입니다.

• 앱 토큰의 비즈니스 모델은 기반이 되는 소프트웨어만큼이나 표현력이 뛰어나야 합니다. 이를 위해 앱이 제공하는 가치에 대한 보상 방식을 사용자가 선택할 수 있는 관대하고 유연한 모델을 만들 수 있는 접근 방식인 앱 토큰을 위한 현금 흐름을 소개합니다. 이 접근 방식은 다양한 관할권에서 합법적인 활동에 대한 수수료를 창출하여 규정 준수를 장려합니다. 동시에, 거버넌스 최소화를 장려하면서 계약에서 발생하는 가치를 극대화할 수 있습니다.

• 여기에서 공유하는 원칙은 탈중앙화 금융(DeFi)부터 탈중앙화 소셜 앱, DePIN 네트워크, 그리고 그 사이의 모든 웹 3.0 앱에 적용됩니다! 모든 영역에 적용됩니다.

토큰 모델의 도전과제

인프라 토큰은 수요가 증가하면 공급이 감소하고, 그에 따라 시장이 조정되는 내재된 공급과 수요의 영향을 받습니다. 그에 따라 시장이 조정됩니다. 많은 인프라 토큰의 이러한 기본 경제 기반은 소각되는 모든 이더 거래에 기본 수수료를 부과하는 이더 개선안 1559(EIP-1559)에 의해 가속화되었습니다. 그러나 구매 및 소각 모델에 대한 산발적인 시도에도 불구하고 앱 토큰에는 EIP-1559와 유사한 모델이 없습니다.

앱은 공급자가 아닌 블록 공간의 <사용자>이기 때문에 블록 공간을 사용하는 다른 사람들로부터 징수하는 가스비에 의존할 수 없습니다. 그렇기 때문에 자체적인 경제 모델을 개발해야 합니다.

여기에는 몇 가지 법적 문제도 있습니다. 인프라 토큰의 경제 모델은 일반적인 블록체인 거래의 일반적인 특성과 절차적 메커니즘으로 인해 법적 위험의 영향을 훨씬 덜 받습니다. 그러나 애플리케이션 토큰의 경제 모델의 경우, 관련 애플리케이션은 규제된 활동의 촉진에 의존할 수 있으며 토큰 보유자의 중개를 관리해야 할 수 있으므로 경제가 더 복잡해질 수 있습니다. 미국에서 엄격한 규제를 받는 파생상품 거래를 촉진하는 탈중앙화 거래소는 이더와는 매우 다릅니다.

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

앱 토큰이 직면한 세 가지 문제 해결에 초점을 맞춘 솔루션

1. 거버넌스 과제

2. 가치 배분의 어려움

3. 규제 활동의 어려움

1. 거버넌스 과제

애플리케이션 토큰에는 일반적으로 거버넌스가 있으며, 탈중앙화 자율 조직(DAO)의 존재는 인프라 토큰에는 없는 불확실성을 야기할 수 있습니다. 미국에서 중요한 사업을 운영하는 DAO의 경우, DAO가 계약의 수익을 통제하거나 계약의 경제 활동을 중개하고 프로그래밍하는 경우 위험이 발생할 수 있습니다. 이러한 위험을 피하기 위해 프로젝트는 거버넌스를 최소화하여 DAO의 통제권을 없앨 수 있습니다. 그렇게 할 수 없는 DAO를 위해 와이오밍주의 새로운 탈중앙화 비법인 비영리 협회(DUNA)는 이러한 위험을 완화하고 관련 세법을 준수하는 데 도움이 될 수 있는 탈중앙화 법인을 제공합니다.

2. 가치 분배 과제

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

프로젝트는 프로젝트에 도움이 되는 방식으로 프로젝트에 기여한 토큰 보유자에게 보상을 제공하는 '이해관계자 자본주의'를 모색해야 합니다. 많은 프로젝트에서 운영 프런트엔드(Liquity), 참여 계약(Goldfinch), 보안 모듈의 일부로 담보 제공(Aave) 등 적극적인 참여를 장려합니다. 여기서 설계 공간은 매우 개방적이지만, 좋은 출발점은 프로젝트의 모든 이해관계자를 나열하고, 어떤 행동에 참여하도록 장려해야 하는지 파악하고, 그러한 인센티브를 통해 계약이 어떤 전반적인 가치를 창출할 수 있는지 결정하는 것입니다.

단순함을 위해 이 글에서는 다른 옵션도 존재하지만 거버넌스 참여에 대해 토큰 보유자에게 보상하는 간단한 보상 모델을 가정하겠습니다.

3. 규제 활동의 과제

규제 활동을 촉진하는 애플리케이션은 토큰 홀더의 가치를 축적하는 메커니즘을 설계할 때에도 주의해야 합니다. 이러한 메커니즘이 관련 법률을 준수하지 않는 허가되지 않은 프런트엔드 또는 API를 통해 가치를 축적하는 경우, 토큰 보유자는 불법 활동으로 이익을 얻을 수 있습니다.

이 문제에 대해 제안된 대부분의 해결책은 특정 자산과 관련된 유동성 풀에 대해서만 합의된 수수료를 활성화하는 등 미국에서 허용되는 활동으로 가치 축적을 제한하는 데 초점을 맞추고 있습니다. 이는 프로젝트를 규제 접근법의 최저 공통분모에 맞추게 하고 전 세계적으로 자율적인 소프트웨어 계약의 가치 제안을 약화시킵니다. 또한 거버넌스 최소화 노력을 직접적으로 약화시킵니다. 규제 준수 관점에서 어떤 수수료 전략이 실현 가능한지 결정하는 것은 DAO에 적합한 업무가 아닙니다.

이상적인 세계에서는 프로젝트가 허용되는 활동을 결정하기 위해 DAO에 의존할 필요 없이 해당 활동이 허용되는 모든 관할권에서 수수료를 부과할 수 있어야 합니다. 해결책은 프로토콜 수준에서 규제 준수를 요구하는 것이 아니라, 수수료를 생성하는 프론트엔드 또는 API가 프론트엔드 위치의 관련 법률과 규정을 준수하는 경우에만 프로토콜에서 생성된 수수료가 통과되도록 하는 것입니다. 전 세계 다른 국가에서는 완벽하게 허용되는 활동이라 하더라도 미국에서 앱이 촉진하는 특정 유형의 거래에 대해 수수료를 부과하는 것을 불법으로 규정한다면 앱 토큰의 경제적 가치가 0으로 떨어질 수 있습니다. 수수료의 적립과 분배의 유연성은 궁극적으로 규제 압력에 직면했을 때 회복력을 의미합니다.

핵심 문제: 수수료 추적

수수료 추적은 규정을 준수하지 않는 프론트엔드가 초래할 수 있는 잠재적 위험을 해결하기 위해 필수적입니다. 위험 또는 라이선싱에 따른 계약 체결. 추적 기능을 사용하면 애플리케이션은 토큰 보유자가 발생한 모든 수수료가 토큰 보유자의 관할권에서 법률을 준수하는 프런트엔드에서만 발생하도록 보장할 수 있습니다. 수수료 추적이 불가능하다면, 규정을 준수하지 않는 프런트 엔드에서 축적된 가치(즉, 규정을 준수하지 않는 프런트 엔드에서 징수한 수수료)로부터 토큰 보유자를 분리할 방법이 없어 토큰 보유자를 위험에 빠뜨릴 수 있습니다.

수수료 추적을 가능하게 하기 위해 프로토콜은 2단계 앱 토큰 서약 시스템 설계를 사용할 수 있습니다.

1단계: 수수료를 생성하는 프런트엔드를 식별하고,

2단계: 수수료를 여러 자금 풀로 라우팅합니다. 자금 풀로 라우팅합니다.

프론트엔드 매핑

수수료 추적을 위해서는 도메인 이름을 공개/개인 키 쌍에 매핑해야 합니다. 이 매핑이 없으면 악의적인 프런트엔드가 거래를 스푸핑하여 정직한 도메인 이름에서 발생한 것처럼 위장할 수 있습니다. 암호화를 사용하면 프런트엔드를 "등록"하고, 도메인 이름과 공개 키의 매핑을 변경 불가능하게 문서화하고, 도메인 이름이 실제로 해당 공개 키를 제어한다는 것을 증명하고, 해당 개인 키를 사용하여 트랜잭션에 서명할 수 있습니다. 이를 통해 거래와 그에 따른 수수료를 특정 도메인 이름에 귀속시킬 수 있습니다.

라우팅 수수료

수수료의 출처를 추적할 수 있게 되면 프로토콜이 수수료 할당 방법을 결정할 수 있으며, DAO의 탈중앙화된 거버넌스에 부담을 더하지 않고도 토큰 보유자가 불법 거래로 인한 수수료를 받지 않도록 보호할 수 있습니다. 이 점을 설명하기 위해 토큰 서약을 적용하기 위해 <각> 프런트엔드에 대한 하나의 서약 풀부터 <모든> 프런트엔드에 대한 하나의 서약 풀까지 다양한 설계가 가능하다고 상상해 보시기 바랍니다.

가장 간단한 빌드에서는 각 프런트엔드의 수수료를 특정 프런트엔드 서약 모듈로 라우팅할 수 있습니다. 토큰 보유자는 어떤 프런트엔드를 선택할지 선택함으로써 자신이 받을 수수료를 결정하고, 토큰 보유자를 법적 위험에 처하게 할 수 있는 수수료를 피할 수 있습니다. 예를 들어, 토큰 보유자는 유럽에서 모든 규제 승인을 받은 프런트 엔드와 관련된 모듈에 대해서만 스테이킹을 선택할 수 있습니다. 이 설계는 단순해 보이지만 실제로는 매우 복잡합니다. 50개의 서로 다른 프런트엔드가 있다면 50개의 풀이 있을 수 있으며, 수수료가 희석되면 토큰 가치에 부정적인 영향을 미칠 수 있습니다.

설계 스펙트럼의 다른 쪽 끝에서는 각 프런트엔드에 대한 수수료가 중앙화될 수 있습니다. 를 중앙 집중화할 수도 있지만, 이는 비용 추적이라는 본래의 목적에 어긋납니다. 모든 수수료가 한데 모이면 규정을 준수하는 프런트 엔드와 그렇지 않은 프런트 엔드의 수수료를 구분할 방법이 없기 때문에 나쁜 사과 하나가 전체 통을 망칠 수 있습니다. 토큰 보유자들은 수수료를 전혀 받지 않거나, 관할 구역 내 비준수 프런트엔드에서 불법적인 활동을 통해 이익을 얻을 수 있는 풀에 서약하는 것 중 하나를 선택해야 하는데, 이는 많은 토큰 보유자들의 참여를 막거나 시스템이 DAO가 수수료를 적용할 수 있는 곳을 평가해야 하는 현재의 차선책으로 돌아갈 수 있는 옵션이 될 수 있습니다. 어디.

수수료 추적성 문제 해결을 통한 추적성 문제

이러한 복잡성은 설정으로 해결할 수 있습니다. 누구나 프런트엔드를 만들 수 있고 모든 프런트엔드가 자체 서약 모듈을 가질 수 있는 라이선스 없는 스마트 컨트랙트 프로토콜 애플리케이션을 생각해 봅시다. 이 프로토콜 애플리케이션의 프런트엔드 중 하나를 app.xyz라고 해봅시다.

App.xyz는 해당 애플리케이션이 위치한 관할권의 규정 준수 규칙을 따를 수 있습니다. app.xyz에서 시작된 애플리케이션 활동에는 계약 수수료가 부과됩니다. app.xyz에는 토큰 보유자가 자신의 토큰을 직접 또는 규정을 준수한다고 판단되는 프론트엔드 포트폴리오를 개별적으로 선택하려는 세터에게 맡길 수 있는 자체 서약 모듈이 있습니다. 이러한 토큰 담보 제공자는 자신이 담보로 제공한 프런트엔드 컬렉션에 대한 수수료의 형태로 수익을 받게 됩니다. 프런트엔드에서 100달러의 수수료가 발생하고 토큰 1개를 각각 약정한 100개의 주체가 있다면, 각 주체는 1달러를 받을 자격이 있습니다. 설정자는 처음에 서비스에 대한 수수료를 부과할 수 있습니다. 향후에는 정부가 관할 구역 내 규정을 준수하는 프런트엔드를 체인으로 인증하여 자동화된 설정이라는 부수적인 이점과 함께 소비자를 보호할 수 있습니다.

이 모델의 한 가지 잠재적 위험은 규정을 준수하는 프런트엔드의 관리 오버헤드가 없기 때문에 비준수 프런트엔드가 더 저렴하게 운영될 수 있다는 것입니다. 또한 거래자에게 프런트엔드 비용을 회수하는 모델을 설계하여 회피 행동을 더욱 장려할 수도 있습니다. 두 가지 요인이 이러한 위험을 완화합니다. 첫째, 대부분의 사용자는 실제로 프런트엔드가 현지 법률과 규정을 준수할 것으로 기대합니다. 이는 특히 규제를 받는 대규모 조직의 경우 더욱 그렇습니다. 둘째, 거버넌스는 규칙을 반복적으로 위반하고 애플리케이션의 실행 가능성을 위협하는 비준수 프런트엔드에 대한 최후의 수단 또는 '거부권' 역할을 하여 악의적인 행동을 억제할 수 있습니다.

마지막으로, 등록된 프런트엔드를 통해 시작되지 않은 거래에서 발생하는 모든 수수료는 통합된 서약 모듈에 예치되어 프로토콜의 스마트 컨트랙트와 직접 상호작용하는 봇 및 기타 거래에서 발생하는 수익을 프로토콜이 포착할 수 있게 됩니다.

이론에서 실제까지: 접근 방식 적용

앱 토큰 스택에 대해 더 자세히 살펴봅시다. 프런트엔드 서약을 용이하게 하려면 프로토콜은 프런트엔드가 등록해야 하는 등록 스마트 컨트랙트를 만들어야 합니다.

1. 각 프론트엔드 또는 API는 ENS DNS 통합과 같이 도메인의 DNS 레코드에 특수 TXT 레코드를 추가할 수 있습니다. 이 TXT 레코드에는 프런트엔드에서 생성한 키 쌍의 공개 키가 포함되어 있으며, 일단 생성되면 인증서라고 합니다.

2. 그런 다음 프런트엔드 클라이언트는 register() 함수를 호출하여 도메인 이름을 소유하고 있음을 증명할 수 있습니다. 도메인 이름을 인증서 공개 키에 매핑하거나 그 반대로 매핑하면 이 정보가 저장됩니다.

3. 클라이언트를 통해 트랜잭션이 생성되면 인증서 공개 키로 트랜잭션 로드에 서명합니다. 이 정보는 함께 묶여 애플리케이션의 스마트 컨트랙트에 전달됩니다.

4. 앱의 스마트 계약은 인증서의 유효성을 검사하여 올바른 거래 주체와 일치하고 등록되었는지 확인합니다. 그렇다면 거래가 처리됩니다. 그런 다음 거래에서 생성된 수수료는 도메인 정보(레지스트리에서)와 함께 FeeCollector 컨트랙트로 전송됩니다.

5. FeeCollector는 설정자, 사용자, 검증자 등이 도메인 또는 도메인 그룹에 대해 직접 토큰을 담보할 수 있도록 합니다. 이러한 계약은 각 도메인에 담보된 토큰의 수, 각 주소의 담보 지분, 담보된 기간을 추적해야 합니다. 널리 사용되는 유동성 채굴 구현을 이 콘트랙트 로직의 출발점으로 사용할 수 있습니다.

6. 설정자(또는 수수료 관리 계약 자체에 직접)에게 서약한 사용자는 이후 도메인에 서약한 애플리케이션 토큰의 수에 따라 해당 수수료의 해당 몫을 인출할 수 있습니다. 이 구조는 메타모포/모포 블루와 유사할 수 있습니다.

이 접근 방식은 애플리케이션 DAO 거버넌스 부담을 늘리지 않고도 도입할 수 있습니다. 실제로 프로토콜이 촉진하는 모든 거래에 대해 수수료 스위치를 영구적으로 켜서 프로토콜의 경제 모델에 대한 DAO의 통제권을 제거할 수 있기 때문에 거버넌스 부담을 줄일 수 있습니다.

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

이 원칙은 앱 토큰 경제 모델에 전반적으로 적용되지만, 앱 유형에 따라 다음과 같은 사항도 있을 수 있습니다. 티어 1 또는 티어 2에 구축된 앱, 앱 체인, 롤업을 사용하여 구축된 앱 등 고려해야 할 다른 비용이 있을 수 있습니다.

L1/L2 앱 고려 사항

계층 1 또는 계층 2 블록체인에 구축된 앱은 체인에 직접 스마트 컨트랙트를 배포합니다. 스마트 컨트랙트를 체인에 직접 배포합니다. 사용자가 애플리케이션의 스마트 컨트랙트와 상호작용하면 수수료가 부과됩니다. 이는 일반적으로 소매 사용자와 기본 스마트 콘트랙트 사이의 인터페이스 역할을 하는 사용하기 쉬운 프런트엔드(예: 애플리케이션 또는 웹사이트)를 통해 발생합니다. 이 경우 모든 수수료는 해당 프런트엔드에서 발생합니다. 위의 app.xyz 예시는 티어 1 앱에서 수수료 시스템이 어떻게 작동하는지 보여줍니다.

앱은 큐레이터에 의존하지 않고 프론트엔드 수수료를 필터링하거나 네트워크 수수료에 기여하는 프론트엔드에 대해 화이트리스트 또는 블랙리스트 접근 방식을 취할 수 있습니다. 여기서 목표는 토큰 홀더와 프로토콜 전체가 불법 활동으로부터 이익을 얻거나 혜택을 받지 않고 관할권별 법률과 규정을 준수하도록 하는 것입니다.

화이트리스트 방식에서는 앱이 프론트엔드에 대한 일련의 규칙을 게시하고, 규칙을 준수하는 프론트엔드의 레지스트리를 생성하며, 동의한 프론트엔드에 인증서를 발급하고, 토큰을 서약하여 앱 수수료의 일부를 받도록 요구합니다. 이러한 규칙을 준수하지 않는 프런트엔드는 수수료가 삭감되고 수수료에 기여하는 인증서가 취소됩니다.

블랙리스트 접근 방식에서는 앱이 규칙을 만들 필요는 없지만 앱을 실행하는 프런트엔드에는 권한이 없습니다. 대신, 애플리케이션은 프론트엔드에서 애플리케이션을 사용하도록 허용하기 전에 해당 프론트엔드가 관할권의 규정 준수를 충족한다는 법률 회사의 의견을 제공하도록 요구합니다. 의견이 접수되면 앱은 프런트엔드에 수수료 납부 증명서를 발급하며, 규제 당국으로부터 프런트엔드가 규정을 준수하지 않는다는 통지를 받은 경우에만 앱이 취소됩니다.

수수료 경로는 이전 섹션에 제공된 예시를 반영합니다.

이 두 가지 접근 방식 모두 DAO가 일련의 규칙을 만들고 유지하거나 규정 준수에 대한 법적 의견을 평가해야 하기 때문에 탈중앙 거버넌스의 부담이 크게 증가합니다. 경우에 따라서는 이것이 허용될 수도 있지만, 대부분의 경우 이러한 규정 준수 부담을 설정자에게 아웃소싱하는 것이 더 바람직합니다.

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

애플리케이션 체인은 검증자가 해당 애플리케이션에 대해서만 작동하는 애플리케이션별 블록체인입니다.

이 검증자는 작업의 대가로 보상을 받습니다. 일반적으로 검증자가 토큰 발행량에 따라 보상을 받는 레이어 1 블록체인과 달리, 일부 앱 체인(예: dYdX)은 고객 수수료를 검증자에게 전가합니다.

이 모델에서는 토큰 보유자가 보상을 받으려면 검증자에게 서약해야 합니다. 검증자는 서약을 위해 설정된 모듈이 됩니다.

이 작업 설정은 레이어 1 검증자와는 다릅니다. 애플리케이션 체인 유효성 검사기는 애플리케이션별 트랜잭션을 확인합니다. 이러한 차이로 인해 애플리케이션 체인 검증자는 그들이 촉진하는 기본 활동과 관련된 더 높은 수준의 법적 위험에 노출될 수 있습니다. 따라서 프로토콜은 검증자가 관할 지역의 법률과 자신의 편의에 따라 업무를 수행할 수 있는 자유를 제공해야 합니다. 중요한 것은 검증자 집합이 지리적으로 분산되어 있다면, 애플리케이션 체인의 무허가 특성을 위태롭게 하거나 검열의 심각한 위험에 노출시키지 않고도 이를 수행할 수 있다는 것입니다.

수수료 추적의 이점을 활용하고자 하는 애플리케이션 체인은 수수료 채널까지 티어 1 앱과 유사하게 설계될 것입니다. 그러나 검증자는 프런트엔드 매핑을 사용해 어떤 트랜잭션을 어떤 프런트엔드에서 처리할지 결정할 수 있습니다. 그러면 특정 거래에 대한 수수료는 활성 검증자 집합으로 전달되며, 참여하지 않기로 선택한 비활성 검증자는 이러한 수수료를 놓치게 됩니다. 수수료 관점에서 검증자는 위에서 설명한 서약 모듈 설정자와 동일한 기능을 수행하며, 이러한 검증자에 대한 서약자는 불법적인 활동으로 인한 수익을 받지 않도록 할 수 있습니다. 또한 검증자는 큐레이터를 선출하여 각 관할권에서 규정을 준수하는 프런트엔드를 결정할 수 있습니다.

앱 요약 고려사항

롤업에는 자체 블록 공간이 있지만, 다른 체인의 보안을 상속할 수 있습니다. 오늘날 대부분의 롤업에는 트랜잭션 주문과 포함을 담당하는 단일 시퀀스 생성기가 있지만, 트랜잭션은 '강제 포함'이라는 프로세스를 통해 레이어 1에 직접 제출될 수 있습니다.

이러한 롤업이 애플리케이션에 특화되어 있고 시퀀스 생성기를 고유한 검증자로 설정하는 경우, 해당 시퀀스 생성기에 포함된 거래에서 생성된 수수료는 규정 준수 프런트엔드 세트 또는 공통 풀에 따라 담보자에게 할당할 수 있습니다.

롤업이 시퀀스 생성기 세트를 탈중앙화하면 시퀀스 생성기가 사실상 세트화된 서약 모듈이 되고 수수료 파이프라인은 애플리케이션 체인을 반영하게 됩니다. 시퀀스 생성기는 수수료 할당을 위해 검증자를 대체하며, 각 시퀀스 생성기는 어떤 프런트엔드 수수료를 받아들일지 스스로 결정할 수 있습니다.

앱 토큰을 위한 다양한 모델이 존재하지만, 선별된 서약 풀을 제공하는 것은 앱 고유의 외재적 문제를 해결하는 데 도움이 되는 경로입니다. 앱이 직면한 내재적, 외재적 과제를 인식함으로써 창업자는 프로젝트의 앱 토큰 모델을 처음부터 더 잘 설계할 수 있습니다.

감사: 이 프로젝트를 시작해주신 Porter Smith에게 감사의 말씀을 전합니다.

여기에 표현된 견해는 AH Capital Management, LLC("a16z") 직원 개인의 견해이며 a16z 또는 그 계열사의 견해가 아닙니다. A16Z 또는 그 계열사의 견해.