No public sale is currently active · Official updates: ecoin@efind.com
Developer Guide

Wallets

Wallets should make cryptographic ownership usable without hiding the security responsibilities that come with self-custody.

Docs · Wallets
Protocol status: Draft architecture. eCoin is under development. These pages describe the Version 0.1 design direction and illustrative developer models, not a finalized wire protocol, production API, or live mainnet.

Wallet responsibilities

An eCoin wallet is expected to manage or securely access authorization credentials, construct transactions, obtain current network state, estimate fees when applicable, sign transactions, submit them, and present finality clearly to users.

Keys and account control

The final production signature scheme, derivation standard, address format, and recovery encoding are not yet specified. Wallet developers should therefore isolate cryptographic and address-format logic behind versioned interfaces rather than building assumptions deep into product code.

Self-custody and custodial modes

Version 0.1 intends to support self-custody. A self-custodial wallet gives the user control of the credential required to authorize transactions; a custodial service controls that credential on the user’s behalf. These are materially different security models and should be described accurately in interfaces and documentation.

Backup and recovery

Recovery design is not finalized. If recovery phrases or equivalent secrets are adopted, possession may imply control of the associated assets. Wallet software should never transmit recovery secrets to analytics systems, logs, support forms, or ordinary cloud storage without an explicit, secure design.

Addresses and payment identifiers

The address representation is an open design question. The final format should include network discrimination and error detection and should be suitable for QR codes and copy/paste. Applications must validate the complete destination and network before signing.

Interoperability

The protocol should support multiple wallet implementations. Hardware wallets, mobile wallets, desktop wallets, merchant systems, and future SDKs should be able to interoperate through published standards rather than relying on private behavior of one application.