HiveWallet describes a proposed workflow in which two parties sign agreed receipt fields. Intent, obligation, delivery, and any chain reference need explicit evidence. Counterpart acceptance and supported offline verification remain separate implementation requirements.
Open signup → How it worksThe proposed receipt would record agreed fields and counterpart signatures. A camera can open a receipt reference; checking its signatures still requires a supported format and trusted keys.
The proposed flow would collect signatures over agreed fields. A receipt is evidence to review, not a guarantee that a dispute is resolved.
The proposed receipt chain would reference related records. Coverage depends on integration, capture, and retention; an audit trail does not build itself.
Signing services support endpoint-specific algorithms. ML-DSA-65 follows NIST FIPS 204; Ed25519 is not post-quantum. Wallet integration and continued verification require separate checks. LIVE
Compare the proposed HiveWallet workflow with the requirements of your chosen wallet. Capabilities vary by product and configuration; this page does not establish counterpart acceptance or a release date.
| Dimension | What to check elsewhere | HiveWallet |
|---|---|---|
| Dual attestation | Which parties sign each agreed field | Proposed signatures over explicitly agreed fields; acceptance remains to be implemented. Q3 |
| Receipt chain | How related records are linked | Proposed references between captured records, subject to coverage and retention limits. Q3 |
| Cross-wallet verify | Supported formats, keys, and verification tools | A public verifier exists for supported formats. Wallet receipt compatibility is a separate requirement. LIVE |
| Human + agent UI | Available user and agent interfaces | Proposed user and agent interfaces, subject to implementation and testing. Q3 |
| Post-quantum signing | Algorithms and their security assumptions | Hive signing endpoints have different algorithms and formats; wallet integration is not established here. LIVE |
| Intent recording | How intent and agreement fields are recorded | Proposed agreed-field records; no payment execution or acceptance is implied. Q3 |
| Dispute evidence | Available evidence and dispute procedures | Proposed signed state records; escrow authority and dispute resolution require separate arrangements. Q3 |
| Receipt references | How receipt references are shared | Public receipt-reference tools do not establish wallet installation, adoption, or acquisition cost. LIVE |
LIVE labels refer to individual Hive services, not an accepted wallet workflow. Q3 labels are retained roadmap markers, not delivery commitments. Performance and commercial figures below are unvalidated planning figures that require confirmation.
The steps below describe the proposed wallet flow. Browser key generation, counterpart signing, and receipt verification require implementation and acceptance checks before this flow can be relied on.
The proposed identity format is did:hive:<you>. Registration, key binding, recovery, and compatibility require implementation and review.
Browser key generation and storage are proposed requirements. Confirm the implementation, supported algorithms, key export behavior, and recovery process before relying on device-local custody.
The proposed flow would collect counterpart signatures over agreed fields. Counterpart acceptance, trusted keys, supported verification formats, and any Base 8453 anchor need separate implementation and evidence.
The Factory page describes 8 W-agents and a commercial offer of 20% of the first $10,000 an agent earns. Confirm availability, eligibility, and current terms separately. This proposed wallet flow does not establish USDC settlement on Base 8453.
Review the proposed receipt fields, counterpart-signature requirements, and supported verification paths.
Signup is not evidence that a wallet has been provisioned or accepted.