# Proposal & demo for using NFTs to represent ownership with **URL:** \ **Category:** Research\ **Created:** [December 9, 2024, 7:34am UTC](https://forum.fuel.network/t/proposal-demo-for-using-nfts-to-represent-ownership-with/7237 "2024-12-09T07:34:20Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![david](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/david/32/32_2.png) [@david](https://forum.fuel.network/u/david)\ **Post date:** [December 9, 2024, 7:34am UTC](https://forum.fuel.network/t/proposal-demo-for-using-nfts-to-represent-ownership-with/7237/1 "2024-12-09T07:34:21Z")
As research has been made on gas abstraction and gas sponsorship, such as @bajpai244’s [gas paymaster demo](https://forum.fuel.network/t/fuel-station-gas-paymaster-on-fuel/7078), there’s been discussion around the limitations of Sway’s `msg_sender()` implementation. Specifically, smart contracts that depend on `msg_sender()` will fail if a paymaster includes a separate ETH coin to cover gas fees. Proposals have been made for how to “fix” the `msg_sender` function, such as [my proposal to add “Note” inputs](https://forum.fuel.network/t/proposal-for-note-inputs/7094/3). However, some contributors have raised the point that the entire _concept_ of a universal “sender” should probably be moved away from when building Fuel applications. I’ve put together a demo of an application that features a basic “vault” application, where the owner of each vault is represented by an NFT. Users can manage their vault (depositing or withdrawing) by including the NFT in their transaction and referencing the input or output coins in their function call. > **[GitHub - dmihal/fuel-nft-vault-demo](https://github.com/dmihal/fuel-nft-vault-demo)** > > Contribute to dmihal/fuel-nft-vault-demo development by creating an account on GitHub. I believe this architecture is a more “Fuel-native” approach to permissioning access in smart contracts, and would love to hear the community’s feedback on this approach. ---
**Author:** ![mtchtrnr](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/mtchtrnr/32/3742_2.png) [@mtchtrnr](https://forum.fuel.network/u/mtchtrnr)\ **Post date:** [December 9, 2024, 6:06pm UTC](https://forum.fuel.network/t/proposal-demo-for-using-nfts-to-represent-ownership-with/7237/2 "2024-12-09T18:06:05Z")
From your repo Readme: > When the user wants to deposit funds, they’ll call the `deposit_assets` method with the assets to deposit. They must also include the NFT in the transaction, by “transferring” the NFT to the same address. The `vault_token` parameter of the function call will “point” to the input, using the `Input` option of the `TokenIdentifier`, which will indicate the input index of the NFT. Nit: you often don’t need to constraint the “deposit” endpoint because there isn’t a reason to stop someone from giving money voluntarily, especially when it will cost extra gas. You should only check in the case that people might be taking from others. ---
**Author:** ![david](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/david/32/32_2.png) [@david](https://forum.fuel.network/u/david)\ **Post date:** [December 11, 2024, 4:56am UTC](https://forum.fuel.network/t/proposal-demo-for-using-nfts-to-represent-ownership-with/7237/3 "2024-12-11T04:56:25Z")
True, although the purpose of the demo isn’t really to build a vault, it’s to demonstrate this constraint/permissioning. Demoing it for `deposit` is useful to demo the “create-and-deposit” flow. ---
**Author:** ![furnic](https://avatars.discourse-cdn.com/v4/letter/f/97f17d/32.png) [@furnic](https://forum.fuel.network/u/furnic)\ **Post date:** [December 11, 2024, 5:17pm UTC](https://forum.fuel.network/t/proposal-demo-for-using-nfts-to-represent-ownership-with/7237/4 "2024-12-11T17:17:36Z")
Hey @david ! This idea of access control in sway via tokens is something I put a fair bit of thought into a couple years ago. I was prototyping a generalized access control system inspired by the idea of “Object Capabilities”. [Habitat Chronicles: What Are Capabilities?](http://habitatchronicles.com/2017/05/what-are-capabilities/) TLDR; A **capability** is a token that both designates a resource and authorizes some kind of access to it. The general idea was that a sway contract could mint access control tokens(fungible) and these tokens could be given to other contracts to allow them to access the minting contract. They also (used to have?) the nice property that for a given token id, there was only one contract that could have minted it, so the token itself identifies the resource to which it grants access. I’m not certain, but I think we’ve lost this propertie with changes to support native NFT’s. FWIW, I talked with someone who implemented something similar on Ethereum as well. Overall, I think NFT’s + access control is a fantastic match. 🙂 ---
**Author:** ![dannbbb1](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.fuel.network/dannbbb1/32/3838_2.png) [@dannbbb1](https://forum.fuel.network/u/dannbbb1)\ **Post date:** [December 11, 2024, 5:33pm UTC](https://forum.fuel.network/t/proposal-demo-for-using-nfts-to-represent-ownership-with/7237/5 "2024-12-11T17:33:54Z")
Great demo and approach! I really like how you’re leveraging NFTs for access control, and it’s interesting to see the comparison with the ‘Object Capabilities’ concept. NFTs seem like a great fit for permissioning in Fuel applications, and it’s exciting to see how this can evolve with future improvements!