---
# System prepended metadata

title: 20221116 Jetable question-list from X

---

# 20221116 Jetable question-list from X

## 行业部分

### 1. **公司之前进行过用户访谈，访谈的对象主要是哪些，有什么 takeaways？**

传统公司：
Space Club，新锐说唱团体 BKC，七彩虹科技博物馆，清华大学科技孵化产业园，猫员外精酿酒馆等 100k+ 粉丝的品牌

区块链公司：
EthSign, StarShark 等

主要的业务合作对于传统公司是 Web2 -> Web3 转型，这些公司的用户群体对于 NFT 会员卡可以彰显自己的个性是认同的，也渴望持有第一个 NFT；对区块链公司则是渴望引入 Crypto 圈外更大规模用户使用产品 / 体验游戏。

无论是传统公司还是区块链公司在这里遇到的困难是一致的。圈外用户的教育成本过高，需要**进行 KYC / OTC / 法币出入金 / 交易所注册 / 链上充提现 等难点的无关用户教育**，导致转化率低至 15% 以下。

Jetable 的 Gasless 功能旨在解决以上问题,对公司用户**不需要**额外开发和用户教育即可**快速转化** Web2 用户。

### 2. 公司 BP 中提到，mass market adoption 中最大的 2 个壁垒是 private key management & native assets，除了这两点外还有什么，为什么这两点是最大的壁垒？

在提供更优的 Web3 User Onboarding 的方案上，无论是 **Jetable 基于 EOA 钱包的 RPC 的方案**，还是**智能钱包**方案，努力的方向都是趋同的：

1. Keyless, Smart Contract / MPC
2. Gasless, Jetable
3. Fiat on-ramp，通过类似 Apple Pay 方式直接买小额 native token
4. Web2 Log-in，用传统邮箱作为登录方式 / 私钥管理的一部分
5. SDK 内嵌，类似淘宝 / 饿了么对支付宝的 SDK 内嵌

大部分人都 **over think**，这些方向是显而易见的 ── 想象一个即将出现的 Web3 Killer DApp，一个形态上有和 STEPN 相像之处的手机 App，通过实际的价值创造配合 token 与经济模型，以**类似证券化**的方式让自己的 pro user 成为真实股东（想象 BiliBili 的主要股东是 **GenZ 用户**，而不是大多数交易美股的**中年 Boomer**）形成**正向循环**。

从第一性原理出发，这整个交互都是可以也应当**脱离现有的 CEX** （中心化交易所）完成的。即使这样一个**全民级**的 Killer DApp 做了一定程度的**类证券化**，为什么对于**普通用户**需要频繁地访问**券商**？对于小额的普通用户，一旦基础设施完善，将是对「交易所」**毫无感知**的未来。而这些功能的完善，是在基础设施上摆脱 CEX 的**必由之路**。

很清晰的是，后面 3 个壁垒的推倒是建构在前 2 个的已然完善以上的。

### 3. RPC-level 的解决方案和 API / SDK 或其他级别的解决方案在开发者、终端用户视角中有何差异，我们为什么选择前者？

对于开发者来说，RPC 级别在**自由度和接入便捷性**上有显著的优势，相比 SDK 开发需要大量研究和开发工作，Jetable 只需要**一行代码**即可完整完成接入，并且具有交易的**原生性**，其他方案，目前只有 Meta Transaction，相比 Jetable 具有以下优势：

1. 对用户，正常交易而非不可读签名，Meta Transaction 在用户端的体验是一个签名操作，但内容并非可读内容，而是类似于 json 的交易结构，正常用户无法判断交易的正义性（例如是否是授权所有 USDC / USDT 的作恶签名），但 Jetable **通过常规交易进行**，不存在以上问题
2. 对开发者，Meta Transaction 需要从开发合约的 Day One 做 EIP 2771 的兼容，换言之，不具备向前兼容的能力，但 Jetable 可以做到**完全的向前兼容**，也无需合约的修改


### 4. 如何看 EIP-4337 对应的解决方案逐步成熟、落地后与公司提供的解决方案的竞争？长期来看我们选择的赛道、解决路径是时间的朋友么？

Jetable 是可以在 EIP-4337 成熟后可以直接集成的方案 ── 如果 EIP-4337 成熟，对 Jetable 是有利的。

Jetable 目前是 Blockchain RPC API + Extensions like Gasless, Anti-sybil attack 服务，**并不和钱包 / 智能钱包竞争**，不仅不竞争，Jetable 是 **wallet-agnostic** 的方案，只要智能钱包的 RPC 网络可以自定义，就可以**在智能钱包被使用**。

并且目前智能钱包语境下的 gasless 目前也**依然需要**类似的**代付节点**（relayer）服务 ── 如果每家智能钱包都实现一套代付方案，对 DApp 开发者来说，如此 segment 的接入是不现实的（譬如同时需要在**五家**不同的主流智能合约钱包为**各自的** relayer **充值**来实现代付）。

Jetable 不仅会支持 Smart Contract Wallet，还会对 Smart Contract Wallet 的支持做专门的优化，在智能钱包这端做类似 **relayer aggregator** 的策略。

不得不提的是，「智能钱包」不仅有 EIP-4337 对应的 Smart Contract Wallet 路线，也有基于譬如 MPC 的方案，譬如 ZenGo，在用户获取上并不逊于 Argent，未来在**商业上**获得成功的技术选型**并不是**板上钉钉的，对于这些方案，Jetable 目前的解决方案就足够被满足。

## 公司部分
### 1. 公司选择对标 CloudFlare 的产品延展、商业化逻辑，为何选择 gasless 作为切入点？这个切入点是否足够痛以至于能留住 devs、项目方？计划如何提升留存、复购和 ARPU？

在对标 CloudFlare 的**横向 DNS 业务**上，Jetable 选择的是以 **RPC 及 RPC 插件**作为切入点，以 gasless 作为第一个 feature 的插件；对标 CloudFlare 的**纵向业务**，如静态网站托管，Jetable 选择了 **on-chain hook / trigger**。

gasless 是 onboarding Web2 users 最需要的功能，在早前问题已经讨论。功能本身**开发成本高，周期长，普通团队很难独自完成**，所以作为极大的痛点可以 **leverage** 早期的**用户获取**。

除此之外，Jetable 还会开发 Anti-Sybil Attack、Risk Control Engine、无 MEV 交易 等 RPC 插件。

对项目方来说，技术选型以后，更改是相对困难的（案例比如在上次 call 中提到了 Solana 上 RPCPool 的策略），相比与留存和复购，在 RPC 这部分的 toB 业务上，**我们更关心用户增长**。这点的策略上，和传统的阿里云 / AWS 打法是类似的。

在营收策略上，Jetable 早期更倾向于从直接 toC 的 on-chain hook / trigger 业务上获取，例如 ENS Squatting、"seller rating" token instant dumping，预计上在 2023 年中旬可以实现营收上的 break even。

### 2. 如何比较 gasless 功能的研发难度、开发周期及公司后续计划推出的 Anti-Sybil Attack 等功能？团队是否有以往开发类似产品、功能的经历，后续开发的排期如何计划？

gasless 对于 DApp 方研发困难且周期长，对于譬如传统的 blockchain rpc provider 是**不屑于**做的。以 Alchemy 为例，拓展新业务的路径，依然是**围绕数据**、追求**正统性**，譬如做 NFT 数据（ERC721 实质上是并不标准化的，需要对不同的 collection 做大量的适配，此前只有 OpenSea 完成了这件事，也是 OpenSea 此前的竞争力所在）

Anti-Sybil Attack 为例，CEO Dave 有在传统互联网公司开发反作弊引擎的经验。

2022 Q4：RPC 产品上线，支持所有 EVM 测试网的 RPC 和 Gasless 服务
2023 Q1：RPC 产品支持所有主网的 RPC 和 Gasless 服务，on-chain trigger 部分，2 个样例 toC on-chain trigger 上线
2023 Q2：RPC 插件添加 MEV Protection、Anti-Sybil Attack、Risk Control Engine，继续上线样例 toC on-chain trigger
2023 Q3&Q4：Wallet & DAuth MVP