Skip to content
Zoran Zhou WEB3 LAB Build · Test · Document 中文
Back to Web3 Lab
BUILD BACKEND ENGINEERING

Testnet Digital Asset Wallet Platform

A planned educational platform for documenting wallet API, transaction lifecycle, backend consistency, and product-security decisions on testnets.

EDUCATIONAL TESTNET ONLY UNAUDITED NO REAL FUNDS
EVIDENCE BOUNDARY

Status and verification labels describe only the evidence published on this page. They are not production-readiness or audit claims.

Overview

This record defines the intended scope of a future educational wallet-platform prototype. It is a planning artifact, not a product demonstration. No application code, passing tests, blockchain activity, or production capability is claimed.

Current boundary: planned, educational, testnet-only, unaudited, and designed to use no real funds.

Problem

Digital asset products have to reconcile two different systems: blockchain state and business state. A transaction can be accepted by an RPC provider while the product workflow remains incomplete, duplicated, delayed, or unauthorized.

The planned prototype will explore how a backend can make those boundaries explicit without presenting a simplified demo as production infrastructure.

Planned scope

  • User and wallet API boundaries
  • Ethereum transaction inspection on a testnet
  • ERC-20 event monitoring
  • Withdrawal state-machine design
  • Webhook signature and replay protection
  • JWT authorization and role boundaries
  • Idempotency, retry, and recovery behavior
  • PostgreSQL transaction boundaries and audit logging

Every item above is a target, not an implemented feature.

Architecture baseline

The first architecture record will separate API handling, wallet orchestration, security policy, persistence, provider integration, and blockchain observation. Trust boundaries and failure paths will be documented before an implementation is labeled as a prototype.

Security design targets

Initial security work will focus on authorization, duplicate withdrawal handling, destination binding, webhook replay, sensitive logging, and regression-test evidence. A control will not be labeled fixed or verified until a reproduction and regression test are available.

Known limitations

This project currently has no repository link, running service, external API integration, test report, or audit. Technology names on this page describe the candidate stack only.

Next verification gate

The next public status change requires a minimal local service, a documented transaction state model, and tests that can be reproduced from checked-in evidence.