• Mã thông báo cơ sở hạ tầng - tương ứng với mạng lớp 1 (hoặc phần liền kề trong ngăn xếp điện toán, chẳng hạn như lớp 2 ) - Các mô hình kinh tế của nó đã trưởng thành và được hiểu rộng rãi, và các mô hình này dựa trên cung và cầu của không gian khối. Nhưng đối với các token ứng dụng—các giao thức hợp đồng thông minh triển khai các dịch vụ trên nền tảng blockchain nhằm truyền tải các quyền trong “các doanh nghiệp phân tán”—mô hình kinh tế vẫn đang được phát triển.

• Mô hình kinh doanh của mã thông báo ứng dụng phải mang tính biểu cảm giống như phần mềm cơ bản của nó. Để đạt được mục tiêu này, chúng tôi đã giới thiệu Dòng tiền của Mã thông báo ứng dụng - một phương pháp cho phép ứng dụng tạo ra các mô hình linh hoạt, dễ dãi trong đó người dùng có thể chọn cách thưởng cho giá trị mà họ cung cấp. Cách tiếp cận này tạo ra phí từ các hoạt động pháp lý ở các khu vực pháp lý khác nhau, khuyến khích sự tuân thủ cao hơn. Đồng thời, nó cũng tối đa hóa giá trị tích lũy của giao thức đồng thời khuyến khích quản trị tối thiểu.

• Các nguyên tắc chúng tôi chia sẻ ở đây áp dụng cho tất cả các ứng dụng web3 - từ tài chính phi tập trung (DeFi) đến các ứng dụng xã hội phi tập trung, mạng DePIN và mọi thứ ở giữa.

Những thách thức mà mô hình mã thông báo phải đối mặt

Mã thông báo cơ sở hạ tầng phụ thuộc vào cung và cầu gắn liền: khi nhu cầu tăng, nguồn cung giảm và thị trường sẽ điều chỉnh tương ứng. Nền tảng kinh tế bản địa này cho nhiều mã thông báo cơ sở hạ tầng đã được tăng tốc nhờ Đề xuất cải tiến Ethereum 1559 (EIP-1559), thực hiện phí cơ bản cho tất cả các giao dịch Ethereum sẽ bị đốt cháy. Nhưng bất chấp những nỗ lực lẻ tẻ trong việc mua và đốt các mô hình, mã thông báo ứng dụng không có mô hình nào tương tự như EIP-1559.

Các ứng dụng là người tiêu dùng không gian khối, không phải nhà cung cấp, vì vậy họ không thể dựa vào việc sử dụng không gian khối của mình từ hóa đơn Gas được thu bởi những người khác ở đó . Đây là lý do tại sao họ cần phát triển các mô hình kinh tế của riêng mình.

Ở đây cũng có một số thách thức pháp lý: Mô hình kinh tế của mã thông báo cơ sở hạ tầng ít phức tạp hơn do tính chất chung của các giao dịch chuỗi khối điển hình và các cơ chế lập trình mà chúng sử dụng. Chịu rủi ro pháp lý. Nhưng đối với mô hình kinh tế có mã thông báo ứng dụng, các ứng dụng liên quan có thể dựa vào việc hỗ trợ các hoạt động được quản lý và có thể yêu cầu các bên trung gian quản lý chủ sở hữu mã thông báo – khiến nền kinh tế trở nên phức tạp hơn. Một sàn giao dịch phi tập trung tạo điều kiện thuận lợi cho giao dịch phái sinh được quản lý chặt chẽ ở Hoa Kỳ và rất khác với Ethereum.

Sự kết hợp của những thách thức bên trong và bên ngoài này có nghĩa là mã thông báo ứng dụng đòi hỏi một mô hình kinh tế khác. Với suy nghĩ này, chúng tôi đề xuất một giải pháp khả thi: cách thiết kế giao thức để đền bù cho chủ sở hữu mã thông báo ứng dụng cho các dịch vụ được cung cấp trong khi tối đa hóa doanh thu giao thức, khuyến khích tuân thủ quy định và kết hợp giảm thiểu quản trị. Mục tiêu của chúng tôi rất đơn giản: cung cấp cho các token ứng dụng nền tảng kinh tế tương tự thông qua dòng tiền mà nhiều token cơ sở hạ tầng đã có.

Giải pháp của chúng tôi tập trung vào giải quyết ba vấn đề mà mã thông báo ứng dụng gặp phải:

< li>

Thách thức quản trị

1. Thách thức phân phối giá trị

2. Thách thức về phân phối giá trị

   p>

3. Thách thức trong các hoạt động được quản lý

1. Những thách thức về quản trị

Mã thông báo ứng dụng thường có quyền quản trị và sự tồn tại của các tổ chức tự trị phi tập trung (DAO) có thể mang lại Nó giúp loại bỏ sự không chắc chắn mà mã thông báo cơ sở hạ tầng không có. Đối với các DAO có hoạt động quan trọng ở Hoa Kỳ, rủi ro có thể phát sinh nếu DAO có quyền kiểm soát doanh thu của giao thức hoặc các bên trung gian và chương trình hoạt động kinh tế của giao thức. Để tránh những rủi ro này, các dự án có thể loại bỏ sự kiểm soát của DAO bằng cách giảm thiểu việc quản trị. Đối với các DAO không thể làm như vậy, Hiệp hội phi lợi nhuận phi tập trung (DUNA) mới của Wyoming cung cấp một thực thể pháp lý phi tập trung có thể giúp giảm thiểu những rủi ro này và tuân thủ luật thuế hiện hành.

2. Những thách thức về gán giá trị

Thiết kế ứng dụng Phải cẩn thận cũng được thực hiện khi thiết kế cơ chế phân bổ giá trị cho chủ sở hữu mã thông báo. Việc kết hợp quyền biểu quyết với quyền kinh tế có thể gây lo ngại theo luật chứng khoán của Hoa Kỳ, đặc biệt là các cơ chế đơn giản và dễ hiểu như chia tỷ lệ và hủy mua mã thông báo. Các cơ chế này trông tương tự như việc mua lại cổ tức và cổ phần, có khả năng làm suy yếu lập luận rằng token phải có khung pháp lý khác với vốn chủ sở hữu.

Các dự án nên khám phá chủ nghĩa tư bản của các bên liên quan - khen thưởng những người nắm giữ mã thông báo vì đóng góp của họ cho dự án theo cách có lợi cho sự đóng góp của dự án. Nhiều dự án khuyến khích sự tham gia tích cực, bao gồm vận hành giao diện người dùng (Liquity), tham gia vào giao thức (Goldfinch) và đặt cọc tài sản thế chấp như một phần của mô-đun bảo mật (Aave). Không gian thiết kế ở đây rất cởi mở, nhưng điểm khởi đầu tốt là liệt kê tất cả các bên liên quan trong dự án, xác định những hành vi nào họ nên được khuyến khích thực hiện và quyết định giá trị tổng thể mà giao thức có thể tạo ra thông qua khuyến khích này.

Để đơn giản, trong bài viết này, chúng tôi sẽ giả định một mô hình trả thưởng đơn giản nhằm thưởng cho những người nắm giữ mã thông báo vì đã tham gia quản trị, mặc dù có những kế hoạch khác.

3. Những thách thức của các hoạt động được quản lý

Thúc đẩy các hoạt động được quản lý Các ứng dụng điều chỉnh hoạt động cũng phải cẩn thận khi thiết kế cơ chế tích lũy giá trị cho chủ sở hữu token. Nếu các cơ chế này tích lũy giá trị từ các giao diện người dùng hoặc API không được cấp phép không tuân thủ luật hiện hành, chủ sở hữu mã thông báo có thể thu lợi từ các hoạt động bất hợp pháp.

Hầu hết các giải pháp được đề xuất cho vấn đề này tập trung vào việc hạn chế tích lũy giá trị vào các hoạt động được phép ở Hoa Kỳ—ví dụ: chỉ đối với những hoạt động liên quan đến một số tài sản nhất định. phí giao thức của nhóm thanh khoản được kích hoạt. Điều này hướng tới mẫu số chung thấp nhất của các phương pháp tiếp cận quy định và làm suy yếu đề xuất giá trị của các giao thức phần mềm tự trị toàn cầu. Điều này cũng trực tiếp làm suy yếu các nỗ lực giảm thiểu quản trị. Việc xác định chiến lược tính phí nào khả thi từ góc độ tuân thủ quy định không phải là nhiệm vụ thích hợp đối với DAO.

Trong một thế giới lý tưởng, các dự án có thể thu phí ở bất kỳ khu vực pháp lý nào nơi hoạt động được cho phép mà không cần phải dựa vào DAO để xác định những gì được phép. Giải pháp không phải là yêu cầu tuân thủ quy định ở cấp độ giao thức mà là đảm bảo rằng các khoản phí do giao thức tạo ra chỉ được chuyển tiếp nếu giao diện người dùng hoặc API tạo ra phí tuân thủ luật và quy định hiện hành ở vị trí giao diện người dùng. kết thúc. Nếu Hoa Kỳ quy định việc tính phí đối với một loại giao dịch nhất định được thực hiện bởi một ứng dụng là bất hợp pháp, ngay cả khi hoạt động đó hoàn toàn được cho phép ở bất kỳ quốc gia nào khác trên thế giới, điều đó có thể ảnh hưởng đến giá trị kinh tế của mã thông báo của ứng dụng xuống 0 . Tính linh hoạt trong việc tích lũy và phân bổ phí cuối cùng cũng tương đương với khả năng phục hồi trước áp lực pháp lý.

Vấn đề cốt lõi: theo dõi chi phí

Tính khả thi của chi phí Truy xuất nguồn gốc là rất quan trọng để giải quyết các rủi ro tiềm ẩn có thể phát sinh từ giao diện người dùng không tuân thủ mà không gây ra rủi ro kiểm duyệt hoặc khiến thỏa thuận yêu cầu cấp phép. Với khả năng truy xuất nguồn gốc, các ứng dụng có thể đảm bảo rằng mọi khoản phí do chủ sở hữu mã thông báo tích lũy chỉ đến từ các giao diện người dùng hợp pháp và tuân thủ trong khu vực pháp lý nơi chủ sở hữu mã thông báo cư trú. Nếu không thể truy nguyên các khoản phí thì sẽ không có cách nào để cách ly chủ sở hữu mã thông báo khỏi giá trị được tích lũy từ giao diện người dùng không tuân thủ (tức là phí được thu bởi giao diện người dùng không tuân thủ), điều này có thể khiến chủ sở hữu mã thông báo gặp rủi ro.

Để giúp theo dõi phí, các giao thức có thể được thiết kế bằng hệ thống đặt cược mã thông báo ứng dụng gồm hai bước.

Bước 1: Xác định giao diện người dùng tạo ra chi phí,

Bước 2: Định tuyến phí đến các nhóm khác nhau dựa trên logic tùy chỉnh.

Ánh xạ giao diện người dùng

Việc truy xuất nguồn gốc có tính phí yêu cầu ánh xạ tên miền tới cặp khóa công khai/riêng tư. Nếu không có ánh xạ này, giao diện người dùng độc hại có thể ngụy trang các giao dịch và giả vờ rằng chúng đến từ một miền trung thực. Mật mã học cho phép chúng tôi "đăng ký" giao diện người dùng, ghi lại tên miền vào ánh xạ khóa chung một cách bất biến, chứng minh rằng tên miền thực sự kiểm soát khóa chung đó và sử dụng khóa riêng tư nói trên để ký các giao dịch. Điều này cho phép chúng tôi phân bổ các giao dịch và do đó tính phí cho một miền cụ thể.

Chi phí định tuyến

Sau khi có thể truy nguyên nguồn phí, giao thức có thể quyết định cách phân bổ các khoản phí này, điều này có thể bảo vệ chủ sở hữu mã thông báo khỏi nhận các giao dịch bất hợp pháp. chi phí sẽ không làm tăng gánh nặng quản trị phi tập trung của DAO. Để giúp minh họa điều này, hãy tưởng tượng một loạt các thiết kế khả thi cho việc đặt cược mã thông báo ứng dụng, từ việc có một nhóm đặt cược cho mỗi giao diện người dùng đến một nhóm đặt cược cho tất cả các giao diện người dùng.

Trong bản dựng đơn giản nhất, mỗi khoản phí giao diện người dùng có thể được chuyển đến một mô-đun đặt cược giao diện người dùng cụ thể. Bằng cách chọn giao diện tiền tệ nào để đặt cược, chủ sở hữu mã thông báo sẽ có thể quyết định mức phí nào họ nhận được và tránh mọi khoản phí có thể khiến chủ sở hữu mã thông báo gặp rủi ro pháp lý. Ví dụ: chủ sở hữu mã thông báo có thể chọn chỉ đặt cược vào mô-đun được liên kết với giao diện người dùng đã nhận được tất cả các phê duyệt theo quy định ở Châu Âu. Mặc dù thiết kế này nghe có vẻ đơn giản nhưng thực tế nó khá phức tạp. Nếu có 50 giao diện người dùng khác nhau, có thể có 50 nhóm đặt cược và việc giảm phí có thể có ảnh hưởng xấu đến giá trị mã thông báo.

Ở đầu bên kia của phạm vi thiết kế, chi phí cho mỗi giao diện người dùng có thể được gộp lại với nhau - nhưng điều này làm mất đi mục đích truy xuất nguồn gốc chi phí. Nếu tất cả các chi phí được gộp lại với nhau, sẽ không có cách nào để phân biệt chi phí ở mặt trước tuân thủ với chi phí ở mặt trước không tuân thủ — một quả táo xấu có thể làm hỏng toàn bộ nhóm. Chủ sở hữu mã thông báo sẽ buộc phải lựa chọn giữa việc không chấp nhận bất kỳ khoản phí nào và đặt cược vào nhóm nơi họ sẽ được hưởng lợi từ hoạt động bất hợp pháp của các giao diện không tuân thủ trong phạm vi quyền hạn của họ – một tùy chọn có thể chặn nhiều mã thông báo Sự tham gia của chủ sở hữu có thể khiến hệ thống trở lại trạng thái ban đầu. thiết kế dưới mức tối ưu hiện tại, trong đó DAO phải đánh giá nơi có thể áp dụng phí.

Giải quyết các vấn đề về truy xuất nguồn gốc chi phí thông qua cài đặt

Những vấn đề phức tạp này có thể được giải quyết thông qua cài đặt. Hãy xem xét một ứng dụng giao thức hợp đồng thông minh không được phép mà bất kỳ ai cũng có thể tạo giao diện người dùng và bất kỳ giao diện người dùng nào cũng có thể có mô-đun đặt cược riêng. Hãy gọi một giao diện người dùng của ứng dụng giao thức này là app.xyz.

App.xyz có thể phải tuân theo các quy tắc tuân thủ cụ thể tại khu vực pháp lý nơi nó tọa lạc. Hoạt động ứng dụng bắt nguồn từ app.xyz sẽ phát sinh phí giao thức. App.xyz có mô-đun đặt cược riêng và chủ sở hữu mã thông báo có thể đặt cược mã thông báo của họ trực tiếp vào mô-đun hoặc cho người thiết lập muốn chọn riêng một danh mục các giao diện người dùng mà họ cho là tuân thủ. Những người đặt cược mã thông báo này sẽ nhận được doanh thu dưới dạng phí cho bộ sưu tập giao diện người dùng mà họ đặt cược. Nếu một giao diện người dùng tạo ra 100 đô la phí và 100 thực thể đặt cược mỗi người 1 mã thông báo thì mỗi thực thể sẽ được hưởng 1 đô la. Người thiết lập ban đầu có thể tính phí cho các dịch vụ của họ. Trong tương lai, các chính phủ có thể chứng nhận trực tuyến các giao diện người dùng tuân thủ trong khu vực pháp lý của họ để giúp bảo vệ người tiêu dùng, với lợi ích phụ là tự động hóa thiết lập.

Một rủi ro tiềm ẩn trong mô hình này là giao diện người dùng không tuân thủ có thể vận hành rẻ hơn do thiếu chi phí quản trị của giao diện người dùng tuân thủ -kết thúc. Họ cũng có thể thiết kế các mô hình để thu lại phí ban đầu cho các nhà giao dịch nhằm khuyến khích hơn nữa hành vi né tránh của họ. Hai yếu tố giảm thiểu rủi ro này. Đầu tiên, hầu hết người dùng thực sự mong đợi giao diện người dùng tuân thủ luật pháp và quy định địa phương của họ. Điều này đặc biệt đúng đối với các tổ chức lớn, được quản lý. Thứ hai, quản trị có thể ngăn chặn hành vi xấu bằng cách đóng vai trò là biện pháp cuối cùng hoặc “quyền phủ quyết” đối với các giao diện người dùng không tuân thủ liên tục vi phạm các quy tắc và gây nguy hiểm cho khả năng tồn tại của ứng dụng.

Cuối cùng, tất cả các khoản phí được tạo ra bởi các giao dịch không được thực hiện thông qua giao diện đăng ký sẽ được gửi vào một mô-đun đặt cược thống nhất, cho phép giao thức được các bot và những người khác thu thập trực tiếp bằng giao thức Doanh thu được tạo từ các giao dịch trong tương tác hợp đồng thông minh.

Từ lý thuyết đến thực hành: áp dụng các phương pháp vào thực tiễn

Chúng ta hãy nhìn lại ngăn xếp mã thông báo ứng dụng. Để tạo điều kiện thuận lợi cho việc đặt cược giao diện người dùng, giao thức cần thiết lập hợp đồng thông minh đăng ký và giao diện người dùng cần đăng ký tại đây.

1. Mỗi giao diện người dùng hoặc API có thể thêm một TXT đặc biệt vào bản ghi DNS của Bản ghi tên miền của nó chẳng hạn như tích hợp ENS DNS. Bản ghi TXT này chứa khóa chung của một cặp khóa do giao diện người dùng tạo ra. Khóa chung này sau khi được tạo sẽ được gọi là chứng chỉ.

2. Sau đó, máy khách giao diện người dùng có thể gọi hàm register() và chứng minh rằng nó sở hữu hàm đó tên miền. Ánh xạ tên miền tới khóa công khai chứng chỉ và ngược lại, thông tin này được lưu trữ.

3. Khi một giao dịch được tạo thông qua ứng dụng khách, nó cũng ký trọng tải giao dịch bằng cách sử dụng khóa chung chứng chỉ của nó. Thông tin này được nhóm lại với nhau và chuyển đến hợp đồng thông minh của ứng dụng.

4. Hợp đồng thông minh của ứng dụng xác minh chứng chỉ, kiểm tra xem nó có tương ứng với đúng chủ thể giao dịch và đã được đăng ký hay không. Nếu vậy, giao dịch sẽ được xử lý. Sau đó, phí do giao dịch tạo ra sẽ được gửi đến hợp đồng FeeCollector, cùng với thông tin tên miền (từ cơ quan đăng ký).

5. FeeCollector cho phép người thiết lập, người dùng, người xác minh, v.v. kiểm tra trực tiếp tên miền hoặc nhóm tên miền Stake Token. Các hợp đồng này phải theo dõi số lượng token được đặt cược trên mỗi tên miền, phần chia sẻ của mỗi địa chỉ trong số cổ phần đó và khoảng thời gian chúng đã được đặt cược. Việc triển khai khai thác thanh khoản phổ biến có thể đóng vai trò là điểm khởi đầu cho logic hợp đồng này.

6. Người dùng đã cam kết với người quy định (hoặc cam kết trực tiếp với chính hợp đồng quản lý phí) sau đó có thể sử dụng ứng dụng để đặt cược tên miền name Phần phí chia sẻ tương ứng được trích dựa trên số lượng token. Kiến trúc này có thể tương tự như MetaMorpho/Morpho Blue.

Phương pháp này có thể được giới thiệu mà không tạo thêm gánh nặng quản trị DAO cho ứng dụng. Trên thực tế, trách nhiệm quản trị có thể được giảm bớt do việc chuyển đổi phí có thể được bật vĩnh viễn cho tất cả các giao dịch được giao thức hỗ trợ, từ đó loại bỏ quyền kiểm soát của DAO đối với mô hình kinh tế của giao thức.

Những cân nhắc bổ sung dựa trên loại ứng dụng

Trong khi những các nguyên tắc áp dụng rộng rãi cho mô hình kinh tế mã thông báo ứng dụng, nhưng có thể có những cân nhắc về phí khác tùy thuộc vào loại ứng dụng: các ứng dụng được xây dựng trên Lớp 1 hoặc Lớp 2, Appchains và các ứng dụng được xây dựng bằng cách sử dụng bản tổng hợp.

Những cân nhắc khi đăng ký L1/L2

Tại các ứng dụng trên Chuỗi khối lớp 1 hoặc lớp 2 triển khai các hợp đồng thông minh trực tiếp trên chuỗi. Phí được tính khi người dùng tương tác với hợp đồng thông minh của ứng dụng. Điều này thường xảy ra thông qua giao diện người dùng dễ sử dụng (chẳng hạn như ứng dụng hoặc trang web) đóng vai trò là giao diện giữa người dùng bán lẻ và hợp đồng thông minh cơ bản. Trong trường hợp này, mọi khoản phí sẽ bắt nguồn từ giao diện người dùng đó. Ví dụ trên về app.xyz minh họa cách hệ thống tính phí có thể hoạt động đối với các ứng dụng Cấp 1.

Ứng dụng không thể dựa vào người quản lý để lọc phí giao diện người dùng hoặc chúng có thể danh sách trắng hoặc < em>danh sách đen phương pháp. Mục đích ở đây vẫn là để đảm bảo rằng chủ sở hữu mã thông báo và toàn bộ giao thức không thu lợi hoặc hưởng lợi từ các hoạt động bất hợp pháp và tuân thủ các luật và quy định cụ thể của khu vực pháp lý.

Trong cách tiếp cận danh sách trắng, ứng dụng xuất bản một bộ quy tắc cho giao diện người dùng, tạo sổ đăng ký giao diện người dùng tuân thủ quy tắc, cấp chứng chỉ cho giao diện người dùng chọn tham gia và yêu cầu người dùng đặt cược mã thông báo để nhận một phần phí đăng ký. Nếu một giao diện người dùng không tuân thủ các quy tắc này, họ sẽ bị cắt giảm và bị thu hồi giấy chứng nhận đóng phí.

Trong cách tiếp cận danh sách đen, ứng dụng không phải tạo bất kỳ quy tắc nào, nhưng giao diện người dùng khởi chạy ứng dụng sẽ không được phép. Thay vào đó, ứng dụng sẽ yêu cầu bất kỳ giao diện người dùng nào đưa ra ý kiến ​​từ một công ty luật xác nhận rằng giao diện người dùng tuân thủ phạm vi quyền hạn của họ trước khi cho phép giao diện người dùng đó sử dụng ứng dụng. Sau khi nhận được nhận xét, ứng dụng sẽ cấp giấy chứng nhận đóng góp phí cho giao diện người dùng. Giấy chứng nhận này sẽ chỉ bị thu hồi nếu ứng dụng nhận được thông báo từ cơ quan quản lý rằng giao diện người dùng không tuân thủ.

Đường dẫn chi phí sẽ phản ánh các ví dụ được cung cấp trong các phần trước.

Cả hai cách tiếp cận đều làm tăng đáng kể gánh nặng quản trị phi tập trung, yêu cầu DAO thiết lập và duy trì một bộ quy tắc hoặc đánh giá các luật liên quan đến việc tuân thủ Ý kiến. Trong một số trường hợp, điều này có thể được chấp nhận, nhưng trong hầu hết các trường hợp, tốt nhất là giao trách nhiệm tuân thủ này cho người thiết lập.

Các cân nhắc về chuỗi ứng dụng

Chuỗi ứng dụng dành cho Ứng dụng -blockchain cụ thể có trình xác thực chỉ hoạt động cho ứng dụng đó.

Đổi lại công việc của họ, những người xác thực này sẽ nhận được tiền. Không giống như các chuỗi khối lớp 1, nơi người xác thực thường được khen thưởng dựa trên việc phát hành mã thông báo lạm phát, một số chuỗi ứng dụng (chẳng hạn như dYdX) chuyển phí khách hàng cho người xác thực.

Trong mô hình này, chủ sở hữu mã thông báo phải đặt cọc cho người xác thực để nhận phần thưởng. Trình xác thực sẽ trở thành một mô-đun đặt cược được định cấu hình.

Thiết lập công việc này khác với trình xác thực Cấp 1. Trình xác nhận chuỗi ứng dụng giải quyết các giao dịch cụ thể cho một ứng dụng cụ thể. Vì sự khác biệt này, Người xác thực tiện ích có thể phải chịu mức độ rủi ro pháp lý cao hơn liên quan đến các hoạt động cơ bản mà họ hỗ trợ. Do đó, giao thức phải cung cấp cho người xác nhận quyền tự do thực hiện công việc của họ theo luật pháp thuộc thẩm quyền của họ và sự thoải mái của chính họ. Điều quan trọng là điều này có thể được thực hiện mà không gây nguy hiểm cho tính chất không cần cấp phép của chuỗi ứng dụng hoặc khiến nó gặp rủi ro kiểm duyệt đáng kể, miễn là bộ trình xác nhận của nó bị phân tán về mặt địa lý.

Các chuỗi ứng dụng muốn tận dụng lợi ích của việc truy xuất nguồn gốc phí sẽ có kiến ​​trúc tương tự như các ứng dụng Cấp 1, cho đến tận kênh tính phí. Tuy nhiên, người xác thực sẽ có thể sử dụng ánh xạ giao diện người dùng để xác định giao diện người dùng nào họ muốn xử lý giao dịch. Sau đó, phí cho bất kỳ giao dịch nhất định nào sẽ được chuyển đến nhóm trình xác thực đang hoạt động, trong khi những trình xác thực không hoạt động chọn không tham gia sẽ bỏ lỡ các khoản phí này. Từ góc độ phí, trình xác thực thực hiện chức năng tương tự như trình thiết lập mô-đun đặt cược đã thảo luận ở trên và người đặt cược của những trình xác thực này có thể đảm bảo rằng họ không nhận được thu nhập từ bất kỳ hoạt động bất hợp pháp nào. Người xác thực cũng có thể bầu người quản lý để xác định giao diện người dùng nào tuân thủ trong từng khu vực pháp lý.

Ghi chú tổng hợp ứng dụng

Bản tổng hợp có không gian khối riêng , nhưng có thể kế thừa tính bảo mật của chuỗi khác. Hầu hết các bản tổng hợp ngày nay đều có một trình sắp xếp thứ tự duy nhất chịu trách nhiệm sắp xếp và chứa các giao dịch, mặc dù các giao dịch có thể được gửi trực tiếp đến lớp 1 thông qua một quy trình được gọi là "đưa vào bắt buộc".

Nếu các đợt tổng hợp này dành riêng cho ứng dụng và thiết lập trình sắp xếp chuỗi của chúng làm trình xác thực duy nhất thì các trao đổi được bao gồm trong trình sắp xếp chuỗi đó Các khoản phí được tạo có thể được phân phối giữa các nhà đặt cược dựa trên một bộ cài đặt trên giao diện người dùng tuân thủ hoặc dưới dạng nhóm chung.

Nếu các bản tổng hợp phân cấp tập hợp các trình sắp xếp của chúng, thì các trình sắp xếp sẽ trở thành các mô-đun đặt cược được tập hợp trên thực tế và quy trình tính phí sẽ phản ánh Điều kiện của chuỗi ứng dụng. Trình tạo trình tự thay thế trình xác thực để phân phối phí và mỗi trình tạo trình tự có thể tự quyết định giao diện người dùng nào sẽ chấp nhận phí.

Mặc dù có nhiều mô hình khả thi cho mã thông báo ứng dụng, nhưng việc cung cấp nhóm đặt cược được quản lý là một hướng đi giúp giải quyết các yếu tố bên ngoài dành riêng cho các ứng dụng trong thử thách này. Bằng cách nhận ra những thách thức bên trong và bên ngoài mà các ứng dụng phải đối mặt, người sáng lập có thể thiết kế tốt hơn các mô hình mã thông báo ứng dụng cho dự án của họ ngay từ đầu.

Lời cảm ơn: Chúng tôi xin cảm ơnPorter Smith đã bắt đầu dự án này.

Các quan điểm thể hiện ở đây là quan điểm cá nhân của từng nhân viên AH Capital Management, L.L.C. ("a16z") chứ không phải của a16z. hoặc các chi nhánh của nó Quan điểm của công ty.