🔧 Upgrade to Cadence 1.0 🔧
The highly anticipated Crescendo network upgrade is coming soon with 20+ new Cadence 1.0 features and EVM equivalence.
Building Walletless Applications Using Child Accounts
In this doc, we’ll dive into a progressive onboarding flow, including the Cadence scripts & transactions that go into
its implementation in your app. These components will enable any implementing app to create a custodial account,
mediate the user’s onchain actions on their behalf, and later delegate access of that app-created account to the
user’s wallet. We’ll refer to this custodial pattern as the Hybrid Custody Model and the process of delegating control
of the app account as Account Linking.
Link an existing app account as a child to a newly authenticated parent account
Get your app to recognize “parent” accounts along with any associated “child” accounts
Put it all together to create a blockchain-native onboarding transaction
View fungible and non-fungible Token metadata relating to assets across all of a user’s associated accounts - their
wallet-mediated “parent” account and any “child” accounts
Facilitate transactions acting on assets in child accounts
Note that since account linking is a sensitive action, transactions where an account may be linked are designated by a
topline pragma #allowAccountLinking. This lets wallet providers inform users that their account may be linked in the
signed transaction.
// Create the PrivatePath where we'll create the link
_15
let linkPath = PrivatePath(identifier: linkPathSuffix)
_15
?? panic("Could not construct PrivatePath from given identifier: ".concat(linkPathSuffix))
_15
// Check if an AuthAccount Capability already exists at the specified path
_15
if !account.getCapability<&AuthAccount>(linkPath).check() {
_15
// If not, unlink anything that may be there and link the AuthAccount Capability
_15
account.unlink(linkpath)
_15
account.linkAccount(linkPath)
_15
}
_15
}
_15
}
From there, the signing account can retrieve the privately linked AuthAccount Capability and delegate it to another
account, unlinking the Capability if they wish to revoke delegated access.
Note that in order to link an account, a transaction must state the #allowAccountLinking pragma in the top line of the
transaction. This is an interim safety measure so that wallet providers can notify users they're about to sign a
transaction that may create a Capability on their AuthAccount.
Linking accounts leverages this account link, otherwise known as an AuthAccount Capability, and encapsulates it. The
components and actions involved in this process - what the Capability is
encapsulated in, the collection that holds those encapsulations, etc. is what we'll dive into in this doc.
Parent-Child accounts - For the moment, we’ll call the account created by the app the “child” account and the
account receiving its AuthAccount Capability the “parent” account. Existing methods of account access & delegation (i.e.
keys) still imply ownership over the account, but insofar as linked accounts are concerned, the account to which both
the user and the app share access via AuthAccount Capability will be considered the “child” account.
Walletless onboarding - An onboarding flow whereby an app creates an account for a user, onboarding them to the
app, obviating the need for user wallet authentication.
Blockchain-native onboarding - Similar to the already familiar Web3 onboarding flow where a user authenticates with
their existing wallet, an app onboards a user via wallet authentication while additionally creating an app account and
linking it with the authenticated account, resulting in a hybrid custody model.
Hybrid Custody Model - A custodial pattern in which an app and a user maintain access to an app created account and
user access to that account has been mediated by account linking.
Account Linking - Technically speaking, account linking in our context consists of giving some other account an
AuthAccount Capability from the granting account. This Capability is maintained in standardized resource called a
HybridCustody.Manager, providing its owning user access to any and all of their linked accounts.
Progressive Onboarding - An onboarding flow that walks a user up to self-custodial ownership, starting with
walletless onboarding and later linking the app account with the user’s authenticated wallet once the user chooses to
do so.
Restricted Child Account - An account delegation where the access on the delegating account is restricted according
to rules set by the linking child account. The distinctions between this and the subsequent term ("owned" account) will
be expanding on later.
Owned Account - An account delegation where the delegatee has unrestricted access on the delegating child account,
thereby giving the delegatee presiding authority superseding any other "restricted" parent accounts.
Linking an account is the process of delegating account access via AuthAccount Capability. Of course, we want to do this
in a way that allows the receiving account to maintain that Capability and allows easy identification of the accounts on
either end of the linkage - the user's main "parent" account and the linked "child" account. This is accomplished in the
(still in flux) HybridCustody contract which we'll continue to use in this guidance.
Since account delegation is mediated by developer-defined rules, you should make sure to first configure the resources
that contain those rules. Contracts involved in defining and enforcing this ruleset are
CapabilityFilter and
CapabilityFactory.
The former enumerates those types that are/aren't accessible from a child account while the latter enables the access of
those allowable Capabilities such that the returned values can be properly typed - e.g. retrieving a Capability that can
be cast to Capability<&NonFungibleToken.Collection> for example.
Here's how you would configure an AllowlistFilter and add allowed types to it:
setup_allow_all_filter.cdc
_25
import "CapabilityFilter"
_25
_25
transaction(identifiers: [String]) {
_25
prepare(acct: AuthAccount) {
_25
// Setup the AllowlistFilter
_25
if acct.borrow<&CapabilityFilter.AllowlistFilter>(from: CapabilityFilter.StoragePath) == nil {
_25
acct.save(<-CapabilityFilter.create(Type<@CapabilityFilter.AllowlistFilter>()), to: CapabilityFilter.StoragePath)
_25
}
_25
_25
// Ensure the AllowlistFilter is linked to the expected PublicPath
let filter = acct.borrow<&CapabilityFilter.AllowlistFilter>(from: CapabilityFilter.StoragePath)
_25
?? panic("filter does not exist")
_25
_25
// Add the given type identifiers to the AllowlistFilter
_25
// **Note:** the whole transaction fails if any of the given identifiers are malformed
_25
for identifier in identifiers {
_25
let c = CompositeType(identifier)!
_25
filter.addType(c)
_25
}
_25
}
_25
}
And the following transaction configures a CapabilityFactory.Manager, adding NFT-related Factory objects:
info
Note that the Manager configured here enables retrieval of castable Capabilities. It's recommended that you implement
Factory resource definitions to support any NFT Collections related with the use of your application so that users can
retrieve Typed Capabilities from accounts linked from your app.
setup_factory.cdc
_35
import "CapabilityFactory"
_35
import "NFTCollectionPublicFactory"
_35
import "NFTProviderAndCollectionFactory"
_35
import "NFTProviderFactory"
_35
_35
import "NonFungibleToken"
_35
_35
transaction {
_35
_35
prepare(acct: AuthAccount) {
_35
// Check for a stored Manager, saving if not found
_35
if acct.borrow<&AnyResource>(from: CapabilityFactory.StoragePath) == nil {
_35
let f <- CapabilityFactory.createFactoryManager()
_35
acct.save(<-f, to: CapabilityFactory.StoragePath)
_35
}
_35
// Check for Capabilities where expected, linking if not found
_35
if !acct.getCapability<&CapabilityFactory.Manager{CapabilityFactory.Getter}>(CapabilityFactory.PrivatePath).check() {
In this scenario, a user custodies a key for their main account which maintains access to a wrapped AuthAccount
Capability, providing the user restricted access on the app account. The app maintains custodial access to the account
and regulates the access restrictions to delegatee "parent" accounts.
Linking accounts can be done in one of two ways. Put simply, the child account needs to get the parent account an
AuthAccount Capability, and the parent needs to save that Capability so they can retain access in a manner that also
represents each side of the link and safeguards the integrity of any access restrictions an application puts in place on
delegated access.
We can achieve issuance from the child account and claim from the parent account pattern in either:
We can leverage Cadence’s AuthAccount.Inbox to publish the
Capability from the child account & have the parent claim the Capability in a separate transaction.
Multi-party signed transaction, signed by both the the accounts on either side of the link
Let’s take a look at both.
info
You'll want to consider whether you would like the parent account to be configured with some app-specific resources or
Capabilities and compose you multisig or claim transactions to include such configurations.
For example, if your app deals with specific NFTs, you may want to configure the parent account with Collections for
those NFTs so the user can easily transfer them between their linked accounts.
On the other side, the receiving account claims the published ChildAccount Capability, adding it to the signer's
HybridCustody.Manager.childAccounts indexed on the child account's Address.
We can combine the two transactions in Publish and Claim into a single multi-signed transaction to
achieve Hybrid Custody in a single step.
info
Note that while the following code links both accounts in a single transaction, in practicality you may find it easier
to execute publish and claim transactions separately depending on your custodial infrastructure.
Given the ability to establish an account and later delegate access to a user, apps are freed from the constraints of
dichotomous custodial & self-custodial paradigms. A developer can choose to onboard a user via traditional Web2 identity
and later delegate access to the user’s wallet account. Alternatively, an app can enable wallet authentication at the
outset, creating an app-specific account & linking with the user’s wallet account. As specified above, these two flows
are known as walletless and blockchain-native onboarding respectively. Developers can choose to implement one for
simplicity or both for maximum flexibility.
The following transaction creates an account, funding creation via the signer and adding the provided public key. You'll
notice this transaction is pretty much your standard account creation. The magic for you will be how you custody the key
for this account (locally, KMS, wallet service, etc.) in a manner that allows your app to mediate onchain interactions
on behalf of your user.
This onboarding flow is really a single-transaction composition of the steps covered above. This is a testament to the
power of the complex transactions you can compose on Flow with Cadence!
info
Recall the pre-requisites needed to be satisfied before linking an account:
CapabilityFilter Filter saved and linked
CapabilityFactory Manager saved and linked as well as Factory implementations supporting the Capability Types you'll
want accessible from linked child accounts as Typed Capabilities.
Compared to walletless onboarding where a user does not have a Flow account, blockchain-native onboarding assumes a user
already has a wallet configured and immediately links it with a newly created app account. This enables the app to
sign transactions on the user's behalf via the new child account while immediately delegating control of that account to
the onboarding user's main account.
After this transaction, both the custodial party (presumably the client/app) and the signing parent account will have
access to the newly created account - the custodial party via key access and the parent account via their
HybridCustody.Manager maintaining the new account's ChildAccount Capability.
blockchain_native_onboarding.cdc
_132
#allowAccountLinking
_132
_132
import "FungibleToken"
_132
import "FlowToken"
_132
import "MetadataViews"
_132
_132
import "HybridCustody"
_132
import "CapabilityFactory"
_132
import "CapabilityFilter"
_132
import "CapabilityDelegator"
_132
_132
transaction(
_132
pubKey: String,
_132
initialFundingAmt: UFix64,
_132
factoryAddress: Address,
_132
filterAddress: Address
_132
) {
_132
_132
prepare(parent: AuthAccount, app: AuthAccount) {
_132
/* --- Account Creation --- */
_132
//
_132
// Create the child account, funding via the signing app account
_132
let newAccount = AuthAccount(payer: app)
_132
// Create a public key for the child account from string value in the provided arg
_132
// **NOTE:** You may want to specify a different signature algo for your use case
_132
let key = PublicKey(
_132
publicKey: pubKey.decodeHex(),
_132
signatureAlgorithm: SignatureAlgorithm.ECDSA_P256
_132
)
_132
// Add the key to the new account
_132
// **NOTE:** You may want to specify a different hash algo & weight best for your use case
Aside from implementing onboarding flows & account linking, you'll want to also consider the account funding & custodial
pattern appropriate for the app you're building. The only pattern compatible with walletless onboarding (and therefore
the only one showcased above) is one in which the app custodies the child account's key and funds account creation.
In general, the funding pattern for account creation will determine to some extent the backend infrastructure needed to
support your app and the onboarding flow your app can support. For example, if you want to to create a service-less
client (a totally local app without backend infrastructure), you could forego walletless onboarding in favor of a
user-funded blockchain-native onboarding to achieve a hybrid custody model. Your app maintains the keys to the app
account locally to sign on behalf of the user, and the user funds the creation of the the account, linking to their main
account on account creation. This would be a user-funded, app custodied pattern.
Again, custody may deserve some regulatory insight depending on your jurisdiction. If building for production, you'll
likely want to consider these non-technical implications in your technical decision-making. Such is the nature of
building in crypto.
If you want to implement walletless onboarding, you can stop here as this is the only compatible pattern. In this
scenario, a backend app account funds the creation of a new account and the app custodies the key for said account
either on the user's device or some backend KMS.
In this case, the backend app account funds account creation, but adds a key to the account which the user custodies.
In order for the app to act on the user's behalf, it has to be delegated access via AuthAccount Capability which the
backend app account would maintain in a HybridCustody.Manager. This means that the new account would have two parent
accounts - the user's and the app. While this pattern provides the user maximum ownership and authority over the child
account, this pattern may present unique considerations and edge cases for you as a builder depending on access to the
child account. Also note that this and the following patterns are incompatible with walletless onboarding in that the
user must have a wallet.
As mentioned above, this pattern unlocks totally service-less architectures - just a local client & smart contracts. An
authenticated user signs a transaction creating an account, adding the key provided by the client, and linking the
account as a child account. At the end of the transaction, hybrid custody is achieved and the app can sign with the
custodied key on the user's behalf using the newly created account.
While perhaps not useful for most apps, this pattern may be desirable for advanced users who wish to create a shared
access account themselves. The user funds account creation, adding keys they custody, and delegates secondary access to
some other account.
