I'm designing currently an accountancy app for nano potentially for larger merchants, eg. fashion brands in retail and ecommerce like Adidas or Tommy Hilfiger..
Basically for the situation where most it's suppliers are also offering nano already (accounts payable) and products via payments to the customer in nano too (accounts receivable) - and that without FX transactions inbetween.
For every customer/account payable, the system would generate nano accounts assigned to individual customer in their db plus accounts for each store (random customers).
Redistribution of the income of these rather publicly known nano accounts to eg, pay off suppliers would go via privately created accounts like 'cash' , 'provision', 'salaries-payable', 'accounts-payable' or 'own-funds' accounts of the company.
Suppliers and employees have their own nano addresses for receivables/salary.
That all works perfectly (without central authority) if one feature is in the protocol:
[Feature-Request] Sending Nano privately to an own nano address.
Given my seed s, I have addresses A_s and B_s. In the blockchain of each account, sending Nano from A_s to B_s, would appear like
- send(from: A_s, to: 9999999999, amount x)
- receive(from: 9999999999, to: B_s, amount x)
999999 being either global address or dummy address.
The receiving part would need to be randomized: amount received in random fractions of x, ideally with a random execution of each fraction within specific time frame.
With that, eg.
- Nano can be send from a publically known nano address(receivable addresses in stores) privately to publically ambiguis nano addresses (private created company accounts).
- Nano can be send to a specific purposed 'cash' address(es). Eg., Cash wallets for each supplier and month and cash wallets for each employee and month.
The feature allows support of the opposite use case for individuals as well: For shoppers with private savings and hot wallet for starbucks and co and salary income and living expenses accounts. I privately spend to new/existing own addresses. New address is for the day-to-day hot wallet (cash) or for or specific purpose like netflix payments. Existing own addresses would be my savings account for example from which I can eventually privately spend to new/specific purpose addresses.
So, Sending Nano privately to Nano addresses could break anti money laundering regulations like KYC. Receiving Nano (eg from ineligible donator), I would need to track and send back all unknown transactions and correlate it's aggregates against specific regulations.
It would be crucial that I can only send money privately to my own accounts/blocks.
[Design idea] I'm not too technical, but my feature idea basically is having a second payload type, second to the Nano INT. That payload type would be signature to a function call which
- sends Nano to a global static address, in which it would randomize the input to an encrypted output.
- has a guard that the encrypted output address can only belong to the sender’s wallet.
The randomization could be done by sending random fractions at random times within certain timeframe.
I think the randomization (fractions of the amount send within timeframe) can be done in a wallet already. The protocol would only need to detect this type of transaction so that the sender address is not logged in the receiver's block / ie. in the block lattice (or overwritten by dummy address 999999). Detection itself would need to ensure (Guard) that send_private() can only send privately to addresses of the sender (generated from same seed).
Maybe by having atomic operation send_privately() composed by create() and send(to public key of created address)
When Nano is widely adopted, there would be crowd websites gathering all publicly known wallet addresses to legal persons (like Musk, Jeff Bezos or Tayler Swift) and legal entities (companies like Amazon, Facebook).
The crowd could reveal public relations and calculate the amount of value owned by this legal person at a certain time without knowing the private saving account addresses. Not too bad since it happens to publicly owned entities and to entities being in disgrace by the public/crowd only I think.