forum.onflow.org Open in urlscan Pro
2606:4700::6812:1dd1  Public Scan

Form analysis
1 forms found in the DOM

POST /login

<form id="hidden-login-form" method="post" action="/login" style="display: none;">
  <input name="username" type="text" id="signin_username">
  <input name="password" type="password" id="signin_password">
  <input name="redirect" type="hidden">
  <input type="submit" id="signin-button" value="Log In">
</form>

Text Content

Sign UpLog In
 * 
 * 


HYBRID CUSTODY

Product & Ideas
account-model

You have selected 0 posts.

select all

cancel selecting

Jan 5
1 / 6
Jan 6

19h ago

dete
1
2d


In the world of consumer blockchain, there are two common models for blockchain
key management: user custody (or self custody) and application custody.

User custody is considered the default and best option by the web3 community.
The user keeps their own key(s) on a device in their control (typically a laptop
or phone), and access to that key is managed by software called “a wallet”.
Applications that provide blockchain services to the user make requests to the
wallet, and the wallet examines and presents the request to the user for
approval before executing. This has the advantage of being self-sovereign and it
gives the user absolute control over their assets, while providing them full
protection from lost assets due to failed or attacked service providers.

For users new to web3, setting up self-custody is confusing and creates
friction. The user is expected to install and configure their wallet software
before they have even used the application that requires it. If you’ve been in
the web3 space for a while, you might not remember the confusion of being asked
to remember twelve random words and then authorizing “full access to all
websites” to a bit of software you’ve never heard of before. This is even worse
on mobile, where users are accustomed to getting started without any kind of
account creation (especially not one that requires a second application to be
installed!). Dapper Wallet and others have done their best to streamline this
process, but data shows that it’s still a major drop-off point for user
on-boarding.

In a desire to remove this friction, a large number of application developers
are providing custody for their users. “App custody” gives users a very natural,
web2-style on-boarding experience, and allows the application vendor to sell
their digital products and services using traditional payment methods (e.g.
credit card on web or native in-app purchases on mobile). This approach is
especially attractive for mobile and for companies that already have a
customer-base with account login (like Netflix or Spotify).

App custody has another benefit: The application doesn’t need to pester the user
for permission via the wallet. The app software can manage the contents of the
account they created for the user directly. For example, if a user buys an
on-chain item using in-app purchases (IAP)in a mobile game, they don’t want to
have to jump back to their wallet to approve every interaction with that item.

As valuable as app custody is in creating a great on-boarding experience and
streamlining interactions with games and other application services, it causes
each application to be an isolated island. The power of blockchain assets is
that users can take them out of the experience that originally created them and
use them in other, compatible apps, like peer-to-peer trading marketplaces or in
new products that extend existing experiences.

One way of trying to bridge this gap is to ask users to start with app custody,
and when they’re experienced enough in the web3 ecosystem to get themselves a
self-custody wallet, they can transfer their assets out of the app-managed
account into their private wallet.

This introduces its own difficulties. The world inside the app (the app-custody
account) and the world outside the app (the user-custody account) are
disconnected. The app world doesn’t see – and can’t even request access to – the
assets in the user-custody account. And the user can’t use the world of web3
applications without removing them from the app-custody account, where they are
presumably quite useful! And worst of all, if an app provider shuts down the
user can lose all assets in the app-custody account, with no possibility of
recovery.

Fortunately, there’s an approach that gives us the best of both worlds.

By using account abstraction – specifically, account delegation – one blockchain
account (the “child account”) can delegate control to another account (the
“parent account”). The child account can be accessed using cryptographic keys,
as per usual, but the owner of the parent account can directly access the assets
of the child, as well. Critically, the account granting the delegation (the
“child”) must explicitly provide this access, and can revoke this access at any
time for any reason.

This connection lets us create a hybrid of app custody and self custody that
provides the full benefits of both. A new user, without a self-custody account,
can sign up for a new account without having any wallet software. But when they
are ready for self custody, they can delegate control of the app-custody account
to their self-custody account. Using their own keys, on their own devices, they
can access all of the assets in both accounts, while still allowing the
application to manage the assets in the child account without having to bring up
the wallet software.

Since this delegation relationship is tracked on-chain, the application can see
the connection to the parent account, and can see the assets in that account and
other children accounts associated with it. It can request temporary access to
those assets from the wallet software (using a standard transaction-signing
request), or even propose a moving those assets into the app-custody account to
allow for continuous access.

1 Reply
3



 * CREATED
   
   2d

 * LAST REPLY
   
   19h
 * 5
   
   REPLIES

 * 34
   
   VIEWS

 * 4
   
   USERS

 * 5
   
   LIKES

 * 2
   
   LINKS

 * 3
   
   

liobrasil
1d


Do you plan to introduce account abstraction in Flow blockchain design ?

2 Replies



jeromep
23h


It’s already available 3, hybrid custody would build on that

1


bluesign
21h


This has many benefits, I was a bit hesitant in the beginning about security
side of things, but after reading about use cases and motivation, I think it can
be implemented securely without losing any of the benefits.

Some benefits I see:

 * This will be great for developers: Capability model was too confusing to many
   of the newcomer developers, actually it was even complex for all ( me
   included )

 * Can provide great isolation between dapps.

 * Not requiring signing and allowing dapp to run action on behalf of the user
   without interaction is great UX. This can even make FCL obsolete.

 * it is great for onboarding but also makes dapps to have no excuse to have
   walled gardens anymore, so this has great benefit for users.

 * Wallets even auto create temp accounts when a dapp connected, link to main
   account, and add dapps public key ( so dapp and wallet can use the account at
   the same time )

 * Another good benefit is: now there is a misconception about each account is a
   user and each tx is user interacted, I think this will help to clear that
   misconception.

 * If we can somehow tag this child accounts to dapps, I think it can be a
   valuable metric about dapp usage etc.


dete:

> Critically, the account granting the delegation (the “child”) must explicitly
> provide this access, and can revoke this access at any time for any reason.

I think here “Irrevocable access” can be also equally true. If dapp ( let’s say
TopShot) will onboard me to a child account, I would like my parent account (
let’s say blocto ) should have irrevocable access to that child account ( unless
I want to break the relation )

In general I am really excited about things we can do with this child accounts.

1 Reply
1


dete
liobrasil
19h


All of the features called “Account Abstraction” in the Ethereum community were
available from day 1 as part of Flow’s original design.

There is a FLIP currently being proposed 1 that streamlines account delegation
specifically to make it easier to use – and easier to audit – via AuthAccount
Capabilities. This FLIP isn’t necessary for us to implement Hybrid Accounts, but
I think it makes Hybrid Accounts much cleaner and would prefer we build Hybrid
Accounts in this way before wallets and apps start supporting other methods.
(It’d suck to have multiple competing mechanisms for Hybrid Accounts.)




dete
1
19h


bluesign:

> This can even make FCL obsolete.

I don’t anticipate that it would make FCL entirely unnecessary.

For use-cases like marketplaces, you want to be able to access all of the assets
in all connected accounts, and it totally makes sense to use the classic “app
proposes and wallet approves” transaction flow that we are used to in web3.

I can totally imagine that applications like games could be built without ever
interacting with a wallet via FCL, however!


bluesign:

> I think here “Irrevocable access” can be also equally true. If dapp ( let’s
> say TopShot) will onboard me to a child account, I would like my parent
> account ( let’s say blocto ) should have irrevocable access to that child
> account ( unless I want to break the relation )

I disagree. I mostly disagree because it adds complexity, but it doesn’t really
add security, either.

If the controller of the child account becomes untrustworthy, they can always
just move the assets out of the account; blocking them from revoking the
delegation doesn’t really prevent malicious behaviour.







Reply


SUGGESTED TOPICS

Topic Replies Views Activity Collateral-free Rental NFT Promotes the Development
of Metaverse’s Sharing Economy
Product & Ideas
cadence
6 353 May '22 Non transferable NFTs
Product & Ideas
1 152 Apr '22 Secure Your Digital Assets
Product & Ideas
0 20 10d Benefits of Starting a Metaverse Business
Product & Ideas
0 78 Jul '22 How OpenSea Clone can turn out as your Budget-friendly solution?
Product & Ideas
0 135 Apr '22


WANT TO READ MORE? BROWSE OTHER TOPICS IN PRODUCT & IDEAS OR VIEW LATEST TOPICS.


[EN.SHARE.TOPIC]



Share





Invalid date Invalid date