How could a potential second layer integrated

What / How are the plans in regard second layer integration?

I think a second layer to differentiate between currency usage as cash (current NANO) and as bank account (second layer opport.) would help much in adoption. In a bank account people want to hold savings without fearing becoming a target using NANO in public stores. The want to be able to receive and pay discrete transactions like rent, salary, entertainment subscriptions...
As a currency both cash and bank account use cases are essential. A second layer could easily provide this by e.g., something similar to bitcoin mixers.

How could a potential second layer integrated above the nano protocol? Would the payload need to differentiate between 2 transaction types:

  1. with NANO (int?) payload
  2. bigger payload to allow for an API to second layer

I'm not a Smart Contact expert nor a mathematician, but at The. Very . Minimum. the base layer needs to be able to:

  1. Move funds into a limbo (second layer) area via a special transaction
  2. Move it back into the first layer via another special transaction that mathematically locks into the first transaction

Both those transactions would need to be voted on by the entire online network.

How the second layer works to move those funds around in the meantime can be left to its developer. But that developer can't move them without that base support first.

There's are three dangers that I can think of immediately, with the Layer 2 even existing:

  1. Those limbo funds locked in Nano's version of the "Lightning Network" can't be treated as voting stake.
    So if a very large proportion of all funds were ever left locked into it, it would weaken the Layer 1 security
  2. It doesn't directly add privacy if unique amount 'x' is locked up by someone, and then the same unique amount 'x' pops back up in someone else's account later
  3. Checking for the new State Block type will slightly slow the processing of normal transactions on the network. So perhaps we should wait until Layer 1 is perfect, with excess capacity to spare

I've not even touched the sides of this, and yet my head is spinning already.
Doesn't mean it can't be done, but it would need smarter people than me, and a lot of thought.

Could a second layer not just use a particular account as the aggregator of funds to interact with the network or multiple accounts if needed? The funds would essentially be locked in those accounts until the 2nd layer that holds the keys makes a transaction to move them. Why would they need to move off the existing block lattice completely?

That's effectively what a second layer is. That's why it needs first layer support. Those funds must be considered in limbo, without a vote.

We're saying the same thing, but using different technologies for it.

I’m not sure I understand why they couldn’t vote.

Take an exchange for example. That’s technically a 2nd layer built on nano. They manage on boarding user funds and storing the funds. An exchange hot wallet is much like you described but it can still vote.

The exchange then allows users to transfer and transact nano with other users with none of it being on the block-lattice until a user wants to move their funds somewhere else.

Sorry for this longer comment here, but I actually changed my view on (generic) second layer APIs...my reasoning is the following ...

I wouldn't necessarily think about (turing complete) smart contract support when the Nano protocol would be extended by few more atomic operations as to support few more use cases than digital cash.
Opening the door to fully fledged smart contracts and Security Tokens etc. would only harm Nano's biggest value propositions - instant settlement.

In terms of adoptions, I think it's crucial to be able to stay within the Nano environment and closing loops: As a merchant, I receive Nano and ideally want to pay within Nano for utilities, employees, hotels, car rentals. That would have a strong feedback loop.

This is not really possible with cash and I think crypto has the challenge to bridge cash and bank account purposes as to substitute both, cash and banks hopefully one day :smirk:

I see the base-protocol (sorry, might be too abstract / don't have deeper technical protocol knowledge) being the consensus protocol / ORV.
On top of that, we have the basic methods open, send, receive, change (repr.).

So, what's missing (imho) in terms of atomic, base-layer connected operations:

  • blocking / reserving amounts (for hotels, rental cars)
  • escrow/shared account (eg with husband/wife, partnerships in business)
  • private payments (e.g. p2p payments possible without exposing saving balances)

Hopefully this is more realistic than a generic second layer API.

For private payments, I have the following idea: Essentially something like "new identity" (ie. address) for every day's hot wallet (cash). Funds can be loaded on the hot wallet by the main account (e.g. savings account) sent via new operation which sends the money through a something like the bitcoin mixer = A public address which pools every requests and will settle the transactions / resolve the pool every x hours. The amounts could be received in (random) parts from the pool address.

What do you think? :slight_smile:

Didn't necessarily want to flood with my ideas.
Are there second layer integration considerations currently?

As I understand it the only second layer considerations at this stage are those that are centralised for privacy and contract functionality etc.
Contracts ultimately rely on legal backing so it makes as much sense to have this executed centrally as it does in a decentralised manner without the tradeoffs of decentralisation.

Hm, legal backing / legislations are currently neither global nor sufficiently fair, transparent or democratic. Legislations have changed in the past as to favor beneficiaries of the current financial system / economy (actions from the federal reserve, ecb, PBoC w.r.t. bail-outs, bank runs, money supply / inflation, trade wars and FX rates...).

With Nano (essentially a new global currency), individuals shall be empowered "with the most efficient and accessible digital money possible, connecting them to the global economy in a sustainable way." (taken from the long-term goals of Nano, FAQ nano.org)

I was wondering, if Nano only seeks to connect individuals to the (existing) global economy (dominated by existing financial systems), how is Nano effectively addressing the inefficiencies of it? (focus of Nano, FAQ, what is Nano, nano.org)
I mean, real settlement will always include the volatile FX rates to and from e.g., EUR, USD, GBP, CHF, Tezos, Etherum. And with that, Nano can be priced by the predominant currency of the economy at will and its (effective) properties fee-less and instant are based on goodwill of the current global economy.

Why does the concept of ownership “Be your own bank, not your seed/bills, not your money” not hold for current cash? Because it is less and less worth every day due to inflation and each time money supply is increased by eg, granting loans. For Nano "Be your own bank" is as hard if a merchant needs to exchange Nano payments each time as to pay his expanses and employees in a local currency. (It will always be more expensive than just conducting the value transfer in the original currency).

In my view, empowering Nano to create a (rather than connecting to the) global economy, could drive adoption exponentially.
I find the idea of Nano brilliant with its fixed supply (basically infinite supply, 10^33). The price of consumer goods, investments and wages can solely depend on supply and demand (of the individual item being priced).

If we omit the helper functions of an economy, the democratic state (to provide well-fare, infrastructure, preserve common goods /environment) and the financial market (e.g., driven by Nano),
then an economy can be divided in goods market and (human) factor/labor market only: households buy consumer goods produced by enterprises, worker-coops… with labor traded at the factor market.

With this in mind, in every day life, what is currently not possible with Nano to close the money flow cycle?

Not much is missing, I find :slight_smile: (when we don’t expand the money-purpose picture to security tokens, eg investments/ownerships of enterprises and other assets, which indeed shouldn't be the concern of the Nano protocol. But it would be nice, if Nano could be used for the cash settlement of investments)

On the other hand, what is missing, might be crucial to connect both markets, goods and labor market, so that Nano would be the true exchange of value, rather than a payment tool with permanent FX transactions connecting the 2 markets.

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.

ie.
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)

Implication
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.

1 Like

Yes, but that's an entirely centralized service. The funds are still in their control. It's impossible to "trust" any deal made using those funds without having trust in the exchange.

Funds in a true second layer need to be locked and unavailable for sale to someone else (and without a vote) until there's network consensus agreement on their new ownership.