钱包开发包含哪些内容
快速测试: 用一句话回答:谁持有密钥?如果答案不明确,说明您还没准备好设计。
加密钱包开发涵盖产品决策和软件,使用户能通过您的服务使用数字资产。计划可包括钱包界面、密钥管理方法、交易和兑换流程、链支持、集成、后端服务和监测。我们定义哪些元素属于首次发布,哪些可以等待。
钱包不仅仅是显示余额的界面。用户需要了解他们授权了什么、操作后会发生什么,以及交易未按预期进行时去哪里寻求帮助。这些需求与功能列表一样,影响着流程设计。
开始时,我们会梳理:
- 谁将使用钱包,他们首先需要做什么。
- 产品是托管型还是非托管型。
- 哪种交付格式适合产品:浏览器扩展、移动端还是Telegram Mini App。
- 计划支持哪些链、交易类型和兑换流程。
- 产品需要哪些后端、监测和运营支持。
如果钱包是更广泛产品的一部分,我们可以将其计划与 dApp 开发 或更广泛的 Web3 开发 计划对齐。输出的是一个实用的功能计划和架构方向,而非承诺首次发布包含所有可能的集成。
如何选择钱包类型和平台?
根据您的产品准备承担的责任来选择钱包类型。托管钱包将密钥操作作为服务的一部分管理,而非托管钱包则围绕用户自行控制密钥来设计。这种区别影响用户体验、技术架构和运营模式,因此应在界面细节确定之前解决。
对于托管产品,请尽早让您的法律顾问参与讨论。监管分类是一个法律问题,产品计划应在发布前反映顾问的指导。对于非托管产品,请明确用户如何创建、访问和恢复钱包,并确保界面用通俗语言解释这些操作。
交付格式也会改变工作内容:
| 格式 | 适用场景 | 需要明确的计划 |
|---|---|---|
| 浏览器扩展 | 用户需要在浏览器活动的同时访问钱包 | 扩展体验、权限和交易流程 |
| 移动钱包 | 产品围绕手机使用设计 | 移动端流程、支持的操作和服务连接 |
| Telegram Mini App | 用户应在Telegram产品内访问钱包功能 | Mini App体验、钱包交互和后端需求 |
钱包可以支持多条链,但列表应遵循实际产品需求。对于关联的Telegram产品,将钱包需求与 Telegram 机器人和 Mini App 开发 对齐;对于独立的手机体验,请考虑 移动应用开发。
需要规划的交易流程和集成
围绕集成所支持的用户操作来规划,而不是围绕一长串技术列表。对于每个流程,明确用户看到什么、确认什么、钱包下一步做什么以及产品随后显示什么状态。这有助于在实施开始前识别缺失的需求。
需要定义的常见领域包括:
- 在所选择的产品格式中连接或打开钱包。
- 查看相关余额或资产详情。
- 发送和接收资产,包括用户在确认前需要查看的信息。
- 兑换流程(如果产品包含资产兑换)。
- 多链导航,以及在请求的操作不可用时提供清晰的反馈。
- 后端职责、监测需求和运营支持。
只有当集成符合产品的托管模型和预期的用户旅程时,它才是有用的。在流程审查期间,我们会检查每个提议的连接是否有明确的目的、指定的负责人以及足够的产品上下文来估算其实施。我们还会识别哪些细节仍需您的团队做出决定,例如链的优先级或交易行为。
对于任何关联的智能合约功能,请将钱包计划与 智能合约开发 协调一致。保持公开的产品说明与钱包内指令一致;Web3 网站和落地页 有助于在不拥挤界面的情况下解释钱包的工作原理。
构建过程中您会收到什么
经验法则: 更少的链、更少的功能、一次发布。在真实用户试用后再添加其余部分。
您会收到一份与商定产品需求挂钩的钱包实施计划,随后是按照计划定义的开发工作和审查活动。具体交付物取决于所选的格式、托管模型、集成和发布需求;这些在实施前就已商定,以便双方团队了解包含的内容。
典型的合作涵盖:
- 所选钱包格式的需求和用户流程映射。
- 托管、链、交易和兑换需求的架构决策。
- 商定功能的界面和实施工作。
- 产品需要的集成工作和后端组件。
- 安全审查和外部审计材料准备(如果需要)。
- 交付计划和后续产品决策的交接说明。
我们从钱包流程审查开始:我们梳理预期的用户操作,识别可能改变架构的决策,并将未解决的问题转化为清晰的计划。然后我们商定构建顺序,进行实施,并根据该计划审查结果。您可以通过分享产品简介、目标用户、托管偏好、目标格式、链优先级以及任何现有的技术或合规指导来做好准备。
如果钱包是更大交付的一部分,我们会将其边界与相关的 Web3 开发工作 协调一致。这使依赖关系保持可见,并帮助您的团队决定在钱包可以测试或发布之前必须准备好哪些内容。
处理钱包安全和发布风险
钱包安全通过架构选择、精心设计的流程以及符合商定计划的审查方案来解决。我们尽早识别敏感操作和密钥管理职责,然后在交付计划中根据需要包含安全审查和审计准备。这有助于团队了解哪些内容已经过审查,哪些仍需专家关注。
在开发之前,请准备好任何现有的技术文档、已知的集成要求以及托管产品的法律顾问指导。在审查期间,要求对密钥管理方法、交易处理、后端职责以及问题监测方式提供清晰解释。对于外部审计,请明确由谁进行、需要哪些材料以及如何处理发现的问题;审计准备不等同于独立审计。
托管分类必须在发布前与您的法律顾问确认,并且任何开发团队都无法控制外部审计师的发现、第三方集成的可用性或平台的审查决定。我们可以承诺商定的实施和记录在案的工作,而这些外部决定仍不在构建团队的控制范围内。
为了进行有效的交接,请确保您的团队能够识别商定的钱包计划、已完成的审查工作、未解决的决策和运营职责。这些是在公开发布前需要解决的具体事项,而非隐含的细节。
您的7点钱包规划清单
在开发开始前回答这7个问题。如果您无法回答前两个,请先进行一个简短的探索步骤,然后再开始构建。
- 决定谁持有密钥:用户还是服务。
- 选择平台:扩展、移动端还是Mini App。
- 列出发布时的链和代币。
- 映射3个核心流程:接收、发送和兑换。
- 规划恢复以及用户在出现问题时看到的内容。
- 在发布前预订安全审查。
- 检查您所在市场的法律规则。
术语一览
托管钱包 指由服务方为用户持有密钥的钱包。
非托管钱包:仅由用户持有密钥的钱包。
何时适合定制钱包
当标准钱包体验不支持您产品所需的托管模型、用户旅程或集成时,定制钱包是一个不错的选择。当钱包操作是dApp、移动产品或Telegram体验的核心,并且需要作为该产品的一部分进行设计而非事后添加时,定制钱包也很有意义。
在委托构建之前,请回答以下问题:
- 用户在首次发布中必须能够做什么?
- 谁负责密钥操作和用户支持?
- 发布时需要哪些链和交易类型?
- 产品需要浏览器扩展、移动应用、Telegram Mini App还是组合形式?
- 哪些集成已经选定,哪些仍需调研?
- 发布前必须准备好哪些安全审查和法律指导?
如果您还无法回答托管或首次发布的问题,请从一次有计划的探索性对话开始,而不是将未完成的功能列表视为规范。我们可以帮助您将简介转化为决策,识别依赖关系,并概述合理的构建顺序。将您的产品描述、首选格式、托管假设和已知集成发送给 MarketingExtra;我们将审查材料,并回复定义钱包计划的后续步骤。
发送3项内容:您的托管选择、目标平台和链列表。
如何操作
- 分享产品简介告诉我们钱包服务于谁、用户需要做什么,以及您是否有偏好的交付格式。包括任何现有的技术或法律指导。
- 审查托管和用户流程在推荐实施计划之前,我们梳理关键产品决策、交易需求和未解决的问题。
- 商定架构和计划在开发开始前,您的团队审查提议的格式、链需求、集成、后端需求和安全工作。
- 构建商定的钱包我们实施计划的体验和集成,保持进度和决策对您的团队可见。
- 审查并准备交接我们对照商定的计划检查交付的工作,记录未完成事项,并为发布或审计准备后续步骤。
常见问题
开始钱包开发需要提供什么?
分享简短的产品描述、目标用户、偏好的交付格式、托管假设以及用户需要完成的操作。添加链或集成偏好以及您已有的任何技术或法律指导。我们利用这些材料来识别未决决策并规划首次讨论。
能否开发由我们持有密钥的钱包,还是只能用户持有密钥?
可以。项目可以围绕任一模型进行规划,但选择会改变密钥管理职责、用户流程和产品运营。对于托管产品,请在发布前让您的法律顾问检查其监管分类;我们可以使技术计划与该指导保持一致。
一个钱包能否同时是浏览器扩展和Mini App?
交付格式是计划的一部分,如果产品需要,可以规划多种格式。每种格式都有其自身的用户旅程和集成要求,因此我们首先定义用户应在每种体验中完成的操作,然后商定包含哪些。
能否支持多条链和兑换?
可以,当它们是商定产品需求的一部分时。我们在实施前定义链支持以及交易或兑换流程,包括用户需要查看的内容以及产品应显示的状态。这避免了将多链支持视为未定义的附加功能。
安全审查等同于独立审计吗?
不等同。安全审查和审计准备与独立审计不同。我们可以在商定的计划中包含审查工作和材料准备;如果您需要外部审计,请与相关专家明确其提供方、要求和问题解决流程。
构建一个钱包需要多少周?
时间安排是在了解托管模型、钱包格式、功能计划、集成和审查需求后确定的。一个聚焦的初始发布与一个涵盖多种格式或链的钱包所需的工作不同。我们在开发开始前与您商定顺序和里程碑。
有人能保证托管钱包顺利发布吗?
不能。托管产品的监管分类必须与您的法律顾问确认,第三方审查结果不受开发团队控制。我们可以交付商定的实施和审查工作,记录未决问题,并根据您的指导协调技术计划。
告诉我们您的项目
回答四个简单问题,经理会在1小时内为您发送方案、时间表和价格范围。全程保密。
正在加载表单…