Currently if a payment transaction is sent to an account that doesn’t exist:
if account name is “implicit” (e.g. 64 characters), it gets created
if account name is regular, the transaction fails / funds get refunded
Now, if it’s transaction sent to NEP-141 to non existing contract → it gets recorded there.
Which means that if some top account can permission creation of sub-accounts in predictable way - one can send to non existing on-chain accounts NEP-141, NFTs or other assets.
There is no way to achieve this for native NEAR and actually register the account.
One proposal to address this, is if account xyz.<suffix> doesn’t exist, the <suffix> account gets called with the fallback of the function call and attached money.
The contract deployed at <suffix> wants, it can handle this request in some way, like creating the sub-account or in any other way predefined by this contract.
This definitely adds more complexity to our runtime.
In return it allows to start creating implicit named wallets, both in NEAR Wallet, Metamask and anything else.
But it requires to have an extra hop, what if you send to aa.bb.cc and bb.cc doesn’t exist either. So does it fall back to cc? This makes it unclear in terms of costs.
If it only call 1 hop, then the cost has to be included to make a function call upfront. This makes a regular transfer cost more expensive, because it has to account for the prepayment of the potential function call.
The hex implicit account is more expensive than a regular name transfer.
Overall there are ton of a complexity with doing it.