This document provides a detailed technical description of the Hive Debit project, outlining the various phases of its development following the proposal submitted to the Decentralized Hive Fund (DHF). Throughout this guide, we delve into NFC architecture, transaction security, integration with other payment systems, user experience, and the key mechanisms to ensure efficient and reliable payments.
Across multiple phases, Hive Debit aims to create a secure, user-friendly, and scalable payment ecosystem for both users and merchants. The approach covers everything from cryptography and NFC data storage to solutions for iOS and integration with the Lightning Network.
Phase 1: NFC System Development & Testing
Compatibility with Android POS Terminals
The first step is ensuring compatibility with different types of terminals featuring NFC technology, especially those running on Android. To achieve this:
Tests will be conducted on several brands and models of NFC-enabled devices to read and write data.
Response times, connection stability, and potential interoperability issues (e.g., differences in handling NDEF or binary data) will be measured.
A recommended configuration will be documented to optimize the payment experience.
Risks and Mitigation Measures
Risk: Incompatibility with older firmware.
Mitigation: Implement and test NFC libraries that offer backward compatibility.
Risk: Lags or disconnections in NFC reading.
Mitigation: Adjust reading parameters and increase sensitivity in terminals where possible.
Security Evaluation of NFC Tag Types
Choosing the right NFC chip type is crucial. Hive Debit requires a balance between security and practicality:
NTAG215 and NTAG216: Highly compatible but offer limited encryption.
Desfire EV1 and EV2: Robust encryption, mutual authentication, and larger capacity.
NFC cards with asymmetric cryptography: Each operation is locally signed, reducing the risk of cloning.
For greater flexibility, potential form factors include:
PVC NFC cards.
NFC rings.
Adhesive mini tags.
Technical Benefits and Risks
Benefit: Enhanced security through encrypted data storage.
Risk: Higher costs when using advanced chips.
Mitigation: Providing a range of basic or premium NFC cards.
Cryptographic Authentication for Secure Transactions
Hive Debit relies on:
ECDSA digital signatures to authenticate transactions without exposing private keys.
AES-256 encryption in the chip’s memory to prevent unauthorized reads.
The concept of pre-signed transactions is central to Hive Debit. Using this mechanism, each user can authorize a set of payments with a maximum amount and defined validity period. Thus, during the payment process, the private key is not required in real time.
Detailed Procedure
Generating the Pre-Signed Transaction
In a secure environment, the user creates and signs a payment order (to, amount, memo, limit, etc.).
An identifier links the signature to a specific batch of transactions.
Secure Storage
The transaction is encrypted and can be stored on the Hive Debit server or on the NFC card (if it supports advanced encryption).
A record is kept of the spending limit associated with that pre-signed transaction.
POS Interaction
When the NFC card is tapped, the transaction information—signature, limit, destination, etc.—is retrieved.
The POS sends this data to the Hive Debit server, which validates the signature and checks the limit.
Network Execution
If everything matches, the transaction is broadcast to the network, and a tx_id (transaction ID) is generated.
The amount is deducted from the pre-signed transaction’s limit.
Technical Risks and Benefits
Risk: Unauthorized use of the card if stolen.
Mitigation: Low limits or an optional PIN before authorizing payments.
Risk: Vulnerability in the server that stores the signed transaction.
Mitigation: Encryption, network segmentation, and key rotation policies.
Benefit: The user does not expose their private key when making payments.
Benefit: Quick usage since the signature is already prepared.
Creation or cancellation of pre-signed transactions.
Review of payment history and limit configuration.
Access to support and tutorials.
Design Approach
Accessibility: A straightforward interface for NFC setup.
Scalability: Ability to handle multiple simultaneous requests during peak demand.
Security: Use of HTTPS and session validations for all sensitive operations.
Key Functionality
"Tap to Program": Allows writing NFC information from a reader or mobile device.
Real-Time Notifications: The system notifies the user once a transaction is completed.
Multi-Language: Adaptable to various regions.
Phase 3: iOS Research & Compatibility
On iOS, the main restriction is that Safari does not permit open NFC payments. Therefore, the most viable solution is:
Developing a native app for iPhone or iPad, enabling NFC reading and sending the pre-signed transactions to the network.
Investigating native APIs (Core NFC) to determine the level of access available in each iOS version.
Implementing authentication logic (Face ID or Touch ID) to reinforce security and prevent unauthorized use.
Technical Details & Challenges
iOS NFC Control: Apple limits NFC tag read/write, so the app must use Core NFC and comply with strict guidelines to access the hardware.
Secure Data Storage: The app can store pre-signed transactions and their limits in the Keychain for greater protection.
No Dependency on Safari: All validation and payment logic occurs within the app, bypassing web restrictions.
User Experience: The goal is to make the process as simple as “Open the app, tap the card, and confirm,” maintaining fluidity at the point of sale.
Phase 4: Lightning Network Integration
The goal is also to enable Bitcoin payments via the Lightning Network. However, no final decision has been made yet due to time constraints and the inherent complexity. Some of the considered options include:
Using a Bolt-like System: Designing an NFC card similar to the Bolt Card, linked to Hive Debit balances, enabling instant LN payments.
v4vapp: This solution offers the ability to make Bitcoin payments from Hive or HBD, facilitating micropayments and direct Lightning interconnection.
Operating a Lightning Node and Holding BTC: Hive Debit could maintain BTC reserves and handle internal conversion, though this increases the responsibility of asset custody.
Each approach poses challenges regarding liquidity, conversion, and infrastructure support. Comparative tests will be conducted to determine the best approach for the platform.
Phase 5: Hive to HBD Conversion Mechanism
To maximize the system’s utility:
Merchants can opt to receive HBD even if the user pays in Hive.
The conversion process would happen internally, so the user is not exposed to additional steps.
Key Points
Payment Detection: The system sees that the customer pays in Hive.
Internal Conversion: Hive Debit transparently converts that amount to HBD.
Fund Delivery: The merchant receives HBD in their account.
Phase 6: POS Development for Merchants
The primary goal of the POS is to assure merchants that the payment was finalized and they can verify it easily. The aim is a robust, secure, and user-friendly tool.
Quick Checkout Interface:
The merchant enters the amount to charge.
The POS displays a “waiting” mode for NFC.
When the card is tapped, the pre-signed transaction is read, and validation begins.
Integrated NFC Support:
Includes the necessary libraries to communicate with NFC chips.
Simplifies the “tap to pay” process.
Option to use USB or embedded NFC readers in the device.
Tips & Receipts:
Allows the customer to add a tip before finalizing the sale.
Generates a digital receipt containing transaction details (amount, date, tx_id).
Option to send the receipt via email or instant messaging.
Multi-Currency:
The merchant can choose which currency they want to receive (Hive, HBD, or BTC if Lightning is supported).
If Lightning is available, the POS automatically handles conversion to display the amount in satoshis or fiat.
Real-Time Confirmations:
The POS connects to the Hive Debit server to verify transaction validity and confirm network inclusion.
The merchant sees an on-screen “Payment Successful” message and transaction ID.
A local and cloud record is kept for future reference.
Security & Access Control:
The POS may require merchant log-in to prevent unauthorized use by staff.
Activity logs record who processed the payment, at what time, and for what amount.
QR Code Payments (Additional Option):
To complement NFC, the POS can also display a QR code.
Users can scan this QR with a mobile wallet or Hive Debit app to complete payment.
This feature ensures broader compatibility for devices lacking NFC or for those who prefer scanning a code.
By taking this approach, merchants can rest assured each sale is recorded clearly, verifiably, and securely.
Phase 7: Card Production, Packaging & Distribution
In the final phase, the plan is to:
Manufacture NFC Cards: Set up agreements with card and NFC ring suppliers to ensure quality and durability.
Pre-Funding & Registration: Provide the option to purchase a card with an initial balance, and then link it to the user’s account on the web portal.
Shipping Strategy: Define distribution centers or logistics partners for quick delivery across different regions.
Quality Control: Each card undergoes an NFC validation test prior to shipping.
(Note: The use of tamper-proof seals and unique identifiers is omitted, but functionality checks remain in place to ensure each card works at the time of delivery.)
General Risks and Mitigation Strategies
Card Theft or Loss
Mitigation: Adjustable limits, optional PIN, and remote card deactivation.
Denial-of-Service (DoS) Attacks
Mitigation: Scalable infrastructure with load balancing and monitoring.
Volatility of Crypto Assets
Mitigation: Use of stablecoins (HBD) to reduce fluctuations.
Server Operator Access to Pre-Signed Transactions
A valid concern is whether the individual or entity running the Hive Debit server could misuse their control to access or drain pre-signed transactions. The system’s design addresses this through multiple safeguards:
Encryption at Rest
All stored pre-signed transactions are encrypted, requiring decryption keys that should be secured in a separate system or module (e.g., an HSM). Even with direct database access, the operator cannot trivially read or modify the raw data.
Strict Spend Limits & Time-Bound Validity
Each pre-signed transaction has a maximum spend limit and can be configured to expire. This reduces the possible damage in case of any misuse.
Audit Logs & Alerts
Any suspicious bulk retrieval or repeated attempts to execute transactions can trigger automated alerts.
User Revocation
Users can revoke outstanding pre-signed transactions at will, which immediately invalidates them if they suspect any compromise.
Infrastructure & Role Segregation
The system can separate the roles of database admin, application admin, and encryption key custodian, so no single party has unilateral control.
How Do We Ensure Nobody Has Undue Access to Pre-Signed Transactions?
Not your keys, not your coins is a valid principle in crypto. While Hive Debit doesn’t store private keys, it does hold (or process) pre-signed transactions that can authorize limited spending. Here’s how we reduce the risk that anyone—not even the server operator—can freely exploit these:
Minimize Pre-Signed Amounts: Users should only sign a small buffer of transactions (e.g., daily or weekly spending). This naturally limits the maximum potential loss.
Option to Store Transactions on the NFC Card Itself: In some setups, the pre-signed data may reside only on the card, not the server. If the user never uploads them to a central server, the operator literally never sees them.
Zero Knowledge Storage: Even if the server holds encrypted copies, the system can be designed so that each user has a partial key or passphrase required to decrypt. Without it, the operator can’t read or alter anything.
Automatic or Manual Revocation: At any sign of server compromise, users can instantly revoke all outstanding pre-signed transactions. This kills their validity on-chain or within the Hive Debit logic.
High-Level Monitoring: Real-time logging and anomaly detection can freeze questionable transactions. If a staff member attempts a mass-execution of pre-signed transactions, alarms will trigger.
In short, the principle of “not your keys, not your coins” remains true if you give out unlimited, wide-ranging access. However, Hive Debit’s design aims to mitigate that by giving only narrowly scoped, time-limited, and user-revocable permissions that are worthless once revoked. This substantially lowers the trust burden on the server operator.
Do You Have an Idea or Proposal for Hive Debit?
If you have any suggestions to improve the system or an innovative idea that could be implemented in Hive Debit, feel free to share it. We want this technology to be accessible and beneficial for as many people as possible.
