---
title: Namebase 开发者空投的可验证分发
date: '2020-02-22 07:17:15'
draft: false
summary: 这件事真正有意思的地方，不在营销，而在它展示了如何把资格筛选做成低摩擦、可验证、可自动化的分发过程。
slug: namebase-airdrop-for-developers
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/Ivkpsf8xF
tags:
- crypto
- airdrop
- github
- merkle-tree
topics:
- blockchain
type: post
---

`Namebase` 针对开发者做 `HNS airdrop` 这件事，我觉得有意思的地方不只是“送币吸引注意力”，而是它把资格筛选做成了一种可验证分发机制。

它的条件很简单：`GitHub follower` 超过一定数量的开发者可以领取。

更有意思的是实现方式。它不是靠人工审核一批名单，而是把符合条件的开发者公钥哈希做成一棵 `Merkle Tree`，空投时通过这棵树来校验资格。

这件事说明什么？

说明空投真正值得看的，并不是“发没发币”，而是背后的分发逻辑有没有设计感。

一个好的空投方案，至少要同时满足几件事：

- 目标人群定义清楚
- 验证成本足够低
- 分发过程可自动化
- 结果尽量可审计

而 `Merkle Tree` 这种结构刚好很适合做这件事。它可以把一大批资格数据压成一个可验证承诺，链上链下都比较容易配合，既不需要把全部名单暴露成笨重的中心化数据库操作，也不需要在分发时逐个重做昂贵校验。

所以从产品设计角度看，这类玩法的亮点其实是：

它把“谁应该被激励”这件事，往更程序化、可验证的方向推进了一步。

对开发者生态尤其如此。因为开发者身份本来就部分存在于开放平台和公开贡献记录里，更适合被拿来做这种条件化分发实验。

当然，这种机制也不完美。比如 `GitHub follower` 本身未必就是最好的开发者代表指标，最后还可能引入额外身份认证，体验上也不一定顺滑。

但即便如此，它仍然提供了一个挺有启发的视角：

空投不只是营销动作，它也可以是一次关于身份、筛选和可验证分发机制的产品实验。

<!-- WEIBO_MEDIA_START -->
## 原微博中的媒体

![](./weibo-4474666263607759-1.jpg)
<!-- WEIBO_MEDIA_END -->