{"id":19610823,"url":"https://github.com/onflow/hybrid-custody-scaffold","last_synced_at":"2026-03-19T10:47:26.791Z","repository":{"id":169886087,"uuid":"645961960","full_name":"onflow/hybrid-custody-scaffold","owner":"onflow","description":"Starter template for working with HybridCustody contract suite","archived":false,"fork":false,"pushed_at":"2023-10-18T15:00:49.000Z","size":993,"stargazers_count":2,"open_issues_count":1,"forks_count":1,"subscribers_count":3,"default_branch":"main","last_synced_at":"2025-08-09T03:33:10.536Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Cadence","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/onflow.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2023-05-26T21:40:12.000Z","updated_at":"2023-11-23T05:59:31.000Z","dependencies_parsed_at":null,"dependency_job_id":"d6bec68f-c8ab-449e-8e6e-2d9e6d351133","html_url":"https://github.com/onflow/hybrid-custody-scaffold","commit_stats":null,"previous_names":["sisyphussmiling/hybrid-custody-scaffold"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/onflow/hybrid-custody-scaffold","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/onflow%2Fhybrid-custody-scaffold","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/onflow%2Fhybrid-custody-scaffold/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/onflow%2Fhybrid-custody-scaffold/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/onflow%2Fhybrid-custody-scaffold/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/onflow","download_url":"https://codeload.github.com/onflow/hybrid-custody-scaffold/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/onflow%2Fhybrid-custody-scaffold/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29225721,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-08T06:05:31.539Z","status":"ssl_error","status_checked_at":"2026-02-08T05:58:33.853Z","response_time":57,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-11T10:33:51.577Z","updated_at":"2026-02-08T09:05:02.348Z","avatar_url":"https://github.com/onflow.png","language":"Cadence","funding_links":[],"categories":[],"sub_categories":[],"readme":"# 👋 Welcome Flow Developer!\n\n\u003c!-- ### Contribution Checklist\n\n- [ ] Ensure contents are in sync with source repo: https://github.com/onflow/hybrid-custody\n- [ ] Update the commit hash in @onflow/flow-cli/scaffolds.json: https://github.com/onflow/flow-cli/blob/master/scaffolds.json\n\n--\u003e\n\n\u003e :information_source: Be sure to check out the [Hybrid Custody\n\u003e docs](https://developers.flow.com/concepts/hybrid-custody) for more info and the [source\n\u003e repo](https://github.com/onflow/hybrid-custody) for the full code and contribution history. If you run\n\u003e into any issues with this scaffold, please create an issue\n\u003e [here](https://github.com/onflow/hybrid-custody-scaffold)\n\nThis scaffold was created to help app developers get started building and exploring a Hybrid Custody project. In this\nscaffold, you'll find a simplified template of the contents in\n[@onflow/hybrid-custody](https://github.com/onflow/hybrid-custody).\n\nIf building a production system on these contracts, you might consider using [Git\nSubmodules](https://github.blog/2016-02-01-working-with-submodules/) to ensure your dependencies remain up to date.\n\n# 🔨 Getting started\n\nGetting started can feel overwhelming, but we are here for you. Depending on how accustomed you are to Flow, here's a\nlist of resources you might find useful:\n\n- [Cadence documentation](https://developers.flow.com/cadence/language): here you will find language reference for\n  Cadence, which will be the language in which you develop your smart contracts,\n- [Visual Studio Code](https://code.visualstudio.com/?wt.mc_id=DX_841432) and [Cadence\n  extension](https://marketplace.visualstudio.com/items?itemName=onflow.cadence): we suggest using Visual Studio Code\n  IDE for writing Cadence with the Cadence extension installed, that will give you nice syntax highlitning and\n  additional smart features,\n- [SDKs](https://developers.flow.com/tools#sdks): here you will find a list of SDKs you can use to ease the interaction\n  with Flow network (sending transactions, fetching accounts etc),\n- [Tools](https://developers.flow.com/tools#development-tools): development tools you can use to make your development\n  easier, \n- [Account inspection](https://emulator.flowview.app/): Account inspector for all networks, including your localnet!\n\n**NFT Resources:**\n\n- [flow-nft](https://github.com/onflow/flow-nft): home of the Flow NFT standards, contains utility contracts, examples,\n  and documentation,\n- [nft-storefront](https://github.com/onflow/nft-storefront/): NFT Storefront is an open marketplace contract used by\n  most Flow NFT marketplaces,\n- [Flow NFT Catalog](https://www.flow-nft-catalog.com/): list of NFT contracts on Flow, can be a valuable source to\n  compose new projects or use as example,\n\n# 📦 Project Structure\n\nYour project comes with some standard folders which have a special purpose:\n\n- `cadence/` inside here is where your Cadence smart contracts code lives\n    - `contracts/` location for Cadence contracts go in this folder\n    - `scripts/` location for Cadence scripts goes here\n    - `transactions/` location for Cadence transactions goes in this folder\n- `flow.json` configuration file for your project, you can think of it as package.json. We'll dig more into this in a bit.\n\n# 🤔 What is Hybrid Custody?\n\n\u003e :books: Read the full docs [here](https://developers.flow.com/build/advanced-concepts/account-linking)\n\nThe Hybrid Custody model on Flow enables developers to provide seamless onboarding and in-app experiences while\nsimultaneously empowering users with real ownership and self-sovereignty. With this new custodial model, developers can\ndeliver the benefits of both app and self-custody in a unified experience.\n\n![Hybrid Custody High-Level](./resources/hybrid_custody_high_level.png)\n\nHybrid Custody grants users access to their linked child accounts without needing to interface with the child\naccount's custodial app, and the custodial app can interact with the relevant assets in the child account on behalf of\nthe user in a frictionless UX free from transaction prompts.\n\n## 🧭 The Path to Hybrid Custody\n\n1. The app creates, funds, and manages access to a Flow account initialized on user onboarding. This enables the app to\n   abstract away the complexities of interacting with smart contract powered applications, and focus on creating slick\n   user experiences behind familiar Web2 authentication and fiat denominated payments.\n1. Once a user returns to the app with a self-custodial wallet, they can authenticate their wallet-managed account in\n   the app, allowing the app to give the user's main account delegated access to the app managed account (albeit with\n   some developer-defined restrictions).\n1. Upon linking, the user's main account - now the \"parent\" account - adds the app created account - now the \"child\"\n   account - to a collection of all linked child accounts. At this point, Hybrid Custody is reached!\n\n# 👨‍💻 Start Developing\n\n\u003e :warning: Note that the contracts in this scaffold are still under development and may undergo breaking changes. You\n\u003e can stay up to date on advancements and changes by following the [source\n\u003e repo](https://github.com/onflow/hybrid-custody).\n\n[Install Flow CLI](https://developers.flow.com/tooling/flow-cli/install)\n\nFrom your workspace directory, setup your Flow project from a scaffold\n\n```sh\nflow setup \u003cYOUR_PROJECT_NAME\u003e --scaffold\n```\n\nYou'll be asked to select the scaffold number for this scaffold\n    \n```sh\n✗ Enter the scaffold number:\n```\n    \nGo ahead and enter the scaffold number for Hybrid Custody Project: `[4] Hybrid Custody Project`\n\n```sh\n✔ Enter the scaffold number: 4\n```\n\nNow, to get emulator running and deploy contracts. Change to your project's directory\n    \n```sh\ncd \u003cYOUR_PROJECT_NAME\u003e\n```\n\nRun the emulator\n    \n```sh\nflow emulator --contracts\n```\n\n\u003e :information_source: We use `--contracts` flag to include additional contracts we can then easily import into our project.\n\nDeploy the scaffold project contracts\n    \n```sh\nflow deploy\n```\n\nYou now have a running emulator instance with all project contracts deployed to `emulator-account`. We know this is the\naccount where contracts were deployed because of our `deployments` field in our [flow.json](./flow.json) file:\n\n```json\n{\n    \"deployments\": {\n        \"emulator\": {\n            \"emulator-account\": [\n                \"AddressUtils\",\n                \"StringUtils\",\n                \"ArrayUtils\",\n                \"HybridCustody\",\n                \"CapabilityDelegator\",\n                \"CapabilityFilter\",\n                \"CapabilityFactory\",\n                \"FTProviderFactory\",\n                \"NFTProviderFactory\",\n                \"NFTProviderAndCollectionFactory\",\n                \"NFTCollectionPublicFactory\"\n            ]\n        }\n    }\n}\n```\n\n\u003e :information_source: These contracts are not deployed to a single contract on testnet/mainnet, but are done so here\n\u003e for the sake of simplicity. Refer to contract aliases for contract deployment addresses.\n\n## 🏎️ Interacting with HybridCustody\n\nNow that the project contracts are deployed on a locally running emulator instance, we can start to interact with them.\nLet's check out a ***progressive onboarding*** flow.\n\nWhat is ***progressive onboarding***? It's the process of onboarding a new-to-Web3 user on to your application,\nabstracting away onchain interactions, and on through to Hybrid Custody once they link their accounts.\n\n\u003e :information_source: Make sure that you've performed the steps above and your emulator is running with contracts deployed.\n\n## Create Dev Account\n\nThere are a number of ways you can create accounts for the purposes of your application. You could use a custodial\nservice, craft your own backend account creation and custodial service, or simply run a transaction from an account you\ncontrol. For simplicity and since everything boils down to the fundamentals, we'll continue by simply running an account\ncreation transaction.\n\nIn order to create accounts on Flow, you'll need an account to begin with to both run the transaction and fund account\ncreation. So let's do that via flow CLI:\n\n```sh\nflow accounts create # account name: dev\n```\n\nName the account `dev` and select `Emulator` as your network.\n\nIf you take a look at your [flow.json](./flow.json), you should see the new account under the `accounts` field like so:\n\n```json\n\"dev\": {\n    \"address\": \"e03daebed8ca0615\",\n    \"key\": \"5ea518f98a0c4f6341675e0b1596925cb331856b051744850bfeabf3e6ecddb5\"\n}\n```\n\n\u003e :information_source: Note that your emulator environment tears down after it stops, so even though this `dev` account\n\u003e remains in your flow.json, it will only work for the length of the session in which is was created. Attempting to\n\u003e access this account in a new emulator instance will result in an error.\n\nLastly, we'll want to make sure this account has enough Flow balance to fund new account creation. The\n`emulator-account` is initialized with a sizable balance which we can transfer to the `dev` account - let's transfer\n1000.0 $FLOW:\n\n```sh\nfts cadence/transactions/flow-token/transfer_flow.cdc e03daebed8ca0615 1000.0\n```\n\n## Configure CapabilityFilter \u0026 CapabilityFactory Resources\n\nAs noted in the full docs, the `HybridCustody` contract supports restricted access delegation. This means developers are\nempowered to define limitations on the level of access a parent account can have on app-managed Hybrid Custody\naccounts.\n\nConstructs in `CapabilityFilter` and `CapabilityFactory` contracts are utilized to define and enforce the Capability\nTypes accessible from linked child accounts. The simplest understanding of their respective roles is that a `Filter`\nresource defines the accessible Types and `Factory` structs define the access pattern to retrieve those Capability Types\nfrom an account.\n\nFor concrete examples of each, see [`AllowlistFilter`](./cadence/contracts/hybrid-custody/CapabilityFilter.cdc) and\n[`NFTCollectionPublicFactory`](./cadence/contracts/hybrid-custody/factories/NFTCollectionPublicFactory.cdc)\n\n\u003e :information_source: To learn more about all these components, see the [Account Model\nsection](https://developers.flow.com/concepts/hybrid-custody/guides/account-model) of the full docs.\n\nBefore linking the `child` \u0026 `parent` accounts, we'll need to first configure the `CapabilityFilter.Filter` and\n`CapabilityFactory.Manager` resources. These will define accessible types and access patterns (respectively) from the\nchild account. We'll configure an `AllowlistFilter`, but consider `AllowAllFilter` and `DenylistFilter` as other\npre-built options if you'd like to enforce restrictions on allowable Types, or you can roll you own!\n\n\u003e :warning: Filters are important as they restrict the scope of access a parent account can have on a child account.\n\u003e Sharing account access comes with technical, business and regulatory risks that devs should be careful to mitigate by\n\u003e scoping access to the minimum necessary ([Principle of Least\n\u003e Privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)). The types you include in your filter will\n\u003e vary according to your use case, but most apps will be well served by allowing NFT collection access demonstrated in\n\u003e the following transaction.\n\nFor our purposes, we'll configure a `Filter` and `Manager` to enable access to NFT-related Capabilities, and do so in a\nsingle transaction:\n\n```sh\nflow transactions send cadence/transactions/dev-setup/setup_nft_filter_and_factory_manager.cdc --signer dev \\\n    f8d6e0586b0a20c7 \\\n    ExampleNFT \\\n    --signer dev\n```\n\nThis transaction sets up an `AllowlistFilter`, enabling access to `ExampleNFT` Collection Capabilities as well as a \n`Manager` specifying the access pattern so those Capabilities can be returned as castable types. This means that any \nparent of a child account using these will only be able to access the `ExampleNFT` resources in those child accounts.\n\nAt the end of this, the `dev` account has `CapabilityFilter.AllowAllFilter` and a `CapabilityFactory.Manager` with a\nnumber of `Factory` implementations configured. We'll use Capabilities on each when we link the `child` and `parent`\naccounts.\n\n\u003e :information_source: You can inspect the developer account storage in [FlowView](https://emulator.flowview.app/), a\n\u003e super useful tool! Click on the link and search for the address you want to inspect. At this point, you should see the\n\u003e `AllowAllFilter` and `Manager` resources at their derived paths.\n\n## Walletless Onboarding\n\nNow that we have a funded dev account and we've configured it with the necessary resources \u0026 Capabilities, we can create\nnew app-controlled accounts on Flow. [Walletless onboarding](./transactions/walletless_onboarding.cdc) is really pretty\nsimple - you're creating an account, funding its creation and taking care of custody on behalf of your user.\n\nBut first, we'll need to generate the key to add to the account.\n\n```sh\nflow keys generate\n```\n\nThis will output a public/private key pair we'll use for the account we're about to create. Of course, in your app, you\ncould handle custody any number of ways - store locally in secure enclave, key sharding protocols, KMS, etc. For our\npurposes here, we'll deal with this manually in a minute.\n\nCopy the generated public key and add it as an argument in the following command along with the initial funding amount\nto add to the account we're going to create:\n\n```sh\nflow transactions send cadence/transactions/hybrid-custody/onboarding/walletless_onboarding.cdc \u003cPUBLIC_KEY\u003e \u003cINITIAL_FUNDING_AMOUNT\u003e --signer dev\n```\n\n\u003e :information_source: If you need testnet $FLOW, check out the [testnet faucet](https://testnet-faucet.onflow.org/)\n\u003e :potable_water:\n\nAt the end of this transaction, a new account will be created with the provided public key added at [full\nweight](https://developers.flow.com/concepts/start-here/accounts-and-keys#weighted-keys) (1000.0).\n\nTime to figure out the address of the account we just created. A number of events will be emitted, including\n`flow.AccountsCreated`. You can either look for this event manually in your terminal, or you can run the following\ncommand and refer to the event emitted in the latest block:\n\n```sh\nflow events get flow.AccountCreated\n```\n\n\u003e :information_source: Your app will want to query for this event from the submitted transaction. Check out [this\n\u003e account creation\n\u003e example](https://github.com/onflow/faucet/blob/045ad28cb9c375871246e40a667dfb62202edcc9/lib/flow/account.ts#L43-L75)\n\u003e using FCL for more context on creating a new account \u0026 retrieving its address.\n\nNow that we know the new account's address, we can add it to our flow.json. Of course, your app would manage custody\nmuch more elegantly. Add the following to your flow.json's `accounts` field. Recall the private key we generated\npreviously.\n\n```json\n\"child\": {\n    \"address\": \"0x045a1763c93006ca\",\n    \"key\": \"\u003cGENERATED_PRIVATE_KEY\u003e\"\n}\n```\n\nYou did it - you just completed walletless onboarding!\n\n**Recall we:**\n\n1. Generated a public/private key pair\n1. Submitted a transaction that:\n    1. Created a new account\n    1. Added the public key to that account\n    1. Added initial funds to the new account\n1. Custodied the corresponding private key\n\nThe `child` account in this instance would be an app-managed account. Next, we'll simulate the process of your app's\nuser creating their own wallet-managed account that will be linked to the account we just created to achieve Hybrid\nCustody. But first we need to prepare the `dev` account.\n\n## Create Parent Account\n\nThis step is pretty easy. Simply run:\n\n```sh\nflow accounts create # account name: parent\n```\n\nName the account `parent` and select `Emulator` as your network. Again, you'll find this account automatically added to\nyour flow.json.\n\nIn the progressive onboarding flow, this step emulates your user going to a wallet provider and creating self-managed\naccount. This is the account that will share access on the app-managed `child` account.\n\n## Link Parent \u0026 Child Accounts\n\nTime to link accounts and achieve Hybrid Custody!\n\nThere are two ways we could do this. If we have both accounts sign a single transaction, the link can be done in that\none transaction. However, we could also utilize the\n[`AuthAccount.Inbox`](https://developers.flow.com/cadence/language/accounts#account-inbox) to perform an async account\nlink by first publishing a Capability the parent account later claims.\n\n\u003e :information_source: As the app developer, you can configure a `Display` view when configuring and/or linking a child\n\u003e account. This enables easy identification of the child account's association in the parent account's wallet. However\n\u003e mechanisms to authenticate child account origins are in discussion, and until then wallet providers \u0026 users should\n\u003e beware that child account metadata is a matter of convenience. Associated metadata is not authenticated or\n\u003e immutable.\n\n\u003cdetails\u003e\n\u003csummary\u003ePublish \u0026 Claim\u003c/summary\u003e\n\nWe can configure any necessary resources (`OwnedAccount`) in the child account while publishing a Capability for the\nparent account. In the process, we'll also make sure a `MetadataViews.Display` is associated with the account. This\nconsolidates a number of steps into a single transaction:\n\n```sh\nflow transactions send cadence/transactions/hybrid-custody/setup_owned_account_with_display_and_publish_to_parent.cdc \\\n    120e725050340cab e03daebed8ca0615 e03daebed8ca0615 NAME DESCRIPTION THUMBNAIL_URL \\\n    --signer child\n```\n\nOnce published, we sign with the parent account to claim the Capability. Note that the parent can set a `Filter` of its\nown to prevent access to Capabilities it doesn't want. For our purposes, we'll pass `nil`, but the feature might be\nuseful for custodial wallet providers.\n\nLet's now run the transaction, signing as the `parent` account to claim the \n\n```sh\nflow transactions send cadence/transactions/hybrid-custody/redeem_account.cdc \\\n    045a1763c93006ca nil nil \\\n    --signer parent\n```\n\nAfter both transactions have been sent, Hybrid Custody has been achieved, giving the parent account access to the child\naccount according to the rules defined in the Filter and accessible by the Factories.\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eMulti-Signed\u003c/summary\u003e\n\nLet's prepare a single multi-signed transaction that will link the `child ` and `parent` accounts. Note that the parent\ncan set a `Filter` of its own to prevent access to Capabilities it doesn't want. For our purposes, we'll pass `nil`,\nbut the feature might be useful for custodial wallet providers that wish to prevent access to fungible tokens.\n\nFirst step is to build the transaction:\n\n```sh\nflow transactions build cadence/transactions/hybrid-custody/setup_multi_sig.cdc \\\n    \u003cPARENT__FILTER_ADDRESS?\u003e \u003cCHILD_ACCOUNT_FACTORY_ADDRESS\u003e \u003cCHILD_ACCOUNT_FILTER_ADDRESS\u003e \\\n    --proposer child \\\n    --payer child \\\n    --authorizer child \\\n    --authorizer parent \\\n    --filter payload \\\n    --save setup_multi_sig\n```\n\nWith the transaction built, we need to sign with both signers:\n\n```sh\nflow transactions sign setup_multi_sig --signer child --signer parent --filter payload --save setup_multi_sig\n```\n\nLastly, we'll send the signed transaction:\n\n```sh\nflow transactions send-signed setup_multi_sig\n```\n\n\u003c/details\u003e\n\n\u003e :information_source: Again, you're encouraged to inspect account storage using\n\u003e [FlowView](https://emulator.flowview.app/). It can be helpful to understand the components involved in making Hybrid\n\u003e Custody function.\n\nWe can validate that the accounts have been linked by running a quick script returning `parent`'s linked Hybrid Custody\naccounts.\n\n```sh\nflow scripts execute cadence/scripts/hybrid-custody/get_child_addresses.cdc 120e725050340cab\n```\n\nOn the other end of the link, we can get the parent addresses of a child account:\n\n```sh\nflow scripts execute cadence/scripts/hybrid-custody/get_parents_from_child.cdc 045a1763c93006ca\n```\n\n\n## Blockchain-Native Onboarding\n\nWalletless onboarding lends a fantastic user experience for Web3 newcomers, but what about crypto-native users? \n\nBlockchain-native onboarding enables a user to log in with their wallet-managed account and link with an app-managed\naccount from the get go. This means the user starts your app with a Hybrid Custody account, enabling them to manage\naccessible in-app assets from their main account while maintaining a seamless in-app experience.\n\n\u003e :warning: Before we can submit the blockchain-native onboarding transaction, we need to make sure the\n\u003e `CapabilityFilter` and `CapabilityFactory` resources are configured properly. If you haven't already, check out [that\n\u003e step above](#configure-capabilityfilter--capabilityfactory-resources) before continuing.\n\u003e\n\u003e You'll also want to ensure you've [created a `parent` account](#create-parent-account) to link to.\n\nNow we can run the blockchain-native onboarding transaction, signing as the `dev` and `parent` accounts.\n\nFirst we generate a public/private key pair to assign to the account we'll create in the transaction.\n\n```sh\nflow keys generate\n```\n\nYou'll want to copy the public key as an argument and build the following multi-signed transaction:\n\n```sh\nflow transactions build cadence/transactions/hybrid-custody/onboarding/blockchain_native.cdc \\\n    \u003cPUBLIC_KEY\u003e \u003cINITIAL_FUNDING_AMOUNT\u003e \u003cFACTORY_ADDRESS\u003e \u003cFILTER_ADDRESS\u003e \\\n    --proposer dev \\\n    --payer dev \\\n    --authorizer parent \\\n    --authorizer dev \\\n    --filter payload \\\n    --save blockchain_native\n```\n\nThen we need to sign that transaction:\n\n```sh\nflow transactions sign blockchain_native --signer parent --signer dev --filter payload --save blockchain_native\n```\n\nAnd finally, send the signed transaction\n\n```sh\nflow transactions send-signed blockchain_native\n```\n\nYou'll see a number of events emitted including account creation and account linking events. To validate the parent has\nthe child account added, let's query against the parent account\n\n```sh\nflow scripts execute cadence/scripts/hybrid-custody/get_child_addresses.cdc \u003cPARENT_ADDRESS\u003e\n```\n\nIf you ran through both onboarding tracks, you should see two addresses returned. Otherwise, just the one created and\nlinked in the blockchain-native transaction will be present.\n\n## Sharing Arbitrary Capabilities\n\nAs we saw above, `CapabilityFactory` defines access patterns to retrieve castable Capabilities from accounts. However,\nyour app may require sharing arbitrary Capabilities with a parent account that do not need to be casted. In this case,\nyou can leverage the `CapabilityDelegator` configured in the linking process to share generic Capabilities with a parent\naccount.\n\nYou can think of a `Delegator` as bucket to place generic Capabilities you want to share from child to parent account.\nIt's worth noting that each parent of a `ChildAccount` has a partitioned `Delegator` as determined by the paths the\nunderlying `Delegator` is stored and linked, derived by the parent's address.\n\nFirst, let's configure an ExampleNFT Collection in the child account so we can later share a Capability to it with the\nlinked parent:\n\n```sh\nflow transactions send cadence/transactions/example-nft/setup_full.cdc --signer child\n```\n\nWe can now run a transaction that will add a private ExampleNFT Provider Capability into the `CapabilityDelegator` shared\nwith the parent we linked above:\n\n```sh\nflow transactions send cadence/transactions/delegator/add_private_nft_collection.cdc \u003cPARENT_ADDRESS\u003e --signer child\n```\n\n\u003e :information_source: If this was your app, you'd want to replace the Capability in the transaction we just ran with\n\u003e your app-specific Capability.\n\nNow we can query the private Capability we added to the delegator:\n\n```sh\nflow scripts execute cadence/scripts/delegator/get_all_private_caps.cdc \u003cPARENT_ADDRESS\u003e \u003cCHILD_ADDRESS\u003e\n```\n\nYou should see the ExampleNFT Capability returned, letting you know the Capability was successfully added as a private\nCapability in the `Delegator` partitioned for the parent account. In this case, the Capability was already accessible\nvia the `CapabilityFactory.Manager`, but the same pattern could be used to delegate any other Capability.\n\n# Recap\n\nAfter all of this, you've navigated through creating an app-custodied account, prepared filter rules, linked parent and\nchild accounts to achieve Hybrid Custody, and finally delegated a private Capability!\n\n![Hybrid Custody Low-Level](./resources/hybrid_custody_low_level.png)\n\nZooming out, this is the map of all you've configured. If your emulator is still running, you can inspect each account\nusing [FlowView](https://emulator.flowview.app/) to see each of the resources pictured above in their respective\naccounts.\n\nAs an app developer, you really only need to be concerned with the app-custodied account and the linking process\n(publish \u0026 claim or multi-signed). Once linked, the assets you provide access to in the child account may change, but\nproperly installed filter rules will ensure the user's access to underlying storage is restricted.\n\nThe great news is that by enabling Hybrid Custody, standard resources used in your app can be leveraged across the whole\necosystem while you can focus on delivering stellar in-app experiences! \n\n# 📚 Resources\n\n- [Full Hybrid Custody docs](https://developers.flow.com/concepts/hybrid-custody)\n- [Full Hybrid Custody repo](https://github.com/onflow/hybrid-custody)\n- [#hybrid-custody Discord channel](https://discord.com/channels/613813861610684416/1087374662100602920)\n\n## Deployment Details\n\n| Network | Address                                                                              |\n| ------- | ------------------------------------------------------------------------------------ |\n| Testnet | [0x294e44e1ec6993c6](https://testnet.contractbrowser.com/account/0x294e44e1ec6993c6) |\n| Mainnet | [0xd8a7e05a7ac670c0](https://contractbrowser.com/account/0xd8a7e05a7ac670c0) |\n\n### Hosted `CapabilityFactory` \u0026 `CapabilityFilter` Implementations\n\n\u003e :information_source: `CapabilityFactory.Manager` implementations and `CapabilityFilter.AllowAllFilter` have been\n\u003e deployed to the accounts below for generalized use cases to make account linking as easy as possible. These\n\u003e generalized implementations likely cover most use cases, but you'll want to weigh the decision to use them according\n\u003e to your risk tolerance and specific scenario.\n\n| Use Case | Testnet Address                                                                       | Mainnet Address                         |\n| -------- | ------------------------------------------------------------------------------------- | --------------------------------------- |\n| NFT Capability Factories       | [0x1055970ee34ef4dc](https://f.dnz.dev/0x1055970ee34ef4dc/storage/CapabilityFactory_0x294e44e1ec6993c6) | [0xee9ff4f07a2d6dad](https://f.dnz.dev/0xee9ff4f07a2d6dad/storage/CapabilityFactory_0xd8a7e05a7ac670c0) |\n| FT Capability Factories        | [0x08bed9e8508ed20e](https://f.dnz.dev/0x08bed9e8508ed20e/storage/CapabilityFactory_0x294e44e1ec6993c6) | [0x410aa603925923d9](https://f.dnz.dev/0x410aa603925923d9/storage/CapabilityFactory_0xd8a7e05a7ac670c0) |\n| NFT + FT Capability Factories  | [0x1b7fa5972fcb8af5](https://f.dnz.dev/0x1b7fa5972fcb8af5/storage/CapabilityFactory_0x294e44e1ec6993c6) | [0x071d382668250606](https://f.dnz.dev/0x071d382668250606/storage/CapabilityFactory_0xd8a7e05a7ac670c0) |\n| AllowAllFilter                 | [0xe2664be06bb0fe62](https://f.dnz.dev/0xe2664be06bb0fe62/storage/CapabilityFilter_0x294e44e1ec6993c6) | [0x78e93a79b05d0d7d](https://f.dnz.dev/0x78e93a79b05d0d7d/storage/CapabilityFilter_0xd8a7e05a7ac670c0)  |\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fonflow%2Fhybrid-custody-scaffold","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fonflow%2Fhybrid-custody-scaffold","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fonflow%2Fhybrid-custody-scaffold/lists"}