<p>If you think about it, your smart contact is attached to a specific UTXO. And somehow, in multi user environment, we need to distinguish the true smart contract output from other outputs that might also include this smart contact.</p>
<p>And the way we do this is to put an specific NFT on the output. Because an NFT can only exist once therefore is unique, there can only be one UTxO at the script address that holds the NFT and thus identities your smart contact.</p>
<p>This <a href="https://medium.com/dcspark/every-eutxo-dapp-will-use-nfts-and-heres-why-fd87e6a8c9a6" rel="nofollow noreferrer">article</a> from Robert Kornacki explains it in details, mostly:</p>
<blockquote>
<p>(...) dApp UTXOs having no in-built uniqueness property which make
them clearly and reliably identifiable from others. This can be
potentially capitalized on by bad actors, or may simply cause problems
due to bad protocol design of new devs who are just getting their
bearings. This clearly is a major issue that must be addressed,
however we luckily have a great innovation which tackles this problem
precisely, NFTs.</p>
<p>(...) Because each NFT can only be created once and UTXOs have the ability
to hold tokens, this means that if we put an NFT inside of the UTXO of
the dApp we are deploying we can guarantee that no one else can do the
same. The NFT acts as an unforgable unique identifier that makes it
trivial for anyone and everyone to see which UTXO is the true
deployment of the protocol. Each dApp frontend must merely save the
currency ID of the NFT in order to be able to use it to verify that
any UTXO it finds at the smart contract address has the correct NFT
inside. If the UTXO does not, it is treated as invalid and ignored. It
does not matter whether the invalid UTXO was created by mistake or by
a bad actor on purpose, it is not the correct UTXO that we are looking
for and thus filtered out. To ensure that the uniqueness property is
forever held, the smart contract tied to the UTXO must specify that
the NFT is never allowed to leave the dApp. In other words, every time
someone spends the dApp UTXO, the NFT must be held in an output that
is also locked by the same dApp smart contract (this technically
changes in the context of dApp updates, but we can skip over that for
now). This NFT preservation check is the only code required to
guarantee the uniqueness property of the dApp. If this check is not in
place then it may be possible for a bad actor to steal the NFT and put
it in his deployment, thereby destroying all guarantees we had
originally.</p>
</blockquote>

CC BY-SA 4.0
2021-08-26T18:38:44.200Z
2021-08-26T18:38:44.200Z
Marek Mahut - StakeNuts
<p>I've seen Charles mention this a little bit in some of his videos. He sort of laughs it off like the answer is obvious, but I'm not deep into the technicals. I also had an Ethereum developer bring it up, so I tried to do my own research and could not find the answer. Maybe it's so obvious that it doesn't really require a technical answer, but I'm here for a response either way. Specifically, the Eth dev said:</p>
<p>&quot;Unspent outputs is the issue. Change addresses and smart contract interaction just doesn't vibe. This is exactly why ethereum is account based. Because it's the only rational way to do smart contract interaction.&quot;</p>
<p>Now, obviously there are many dapps from many devs running on the testnet right now, so I'm wondering what the technical rebuttal would be to this concern.</p>
<p>Thanks for all your contribution to the Cardano community!</p>

CC BY-SA 4.0
2021-08-26T18:24:06.367Z
I'm interested in this too. Here is another similar thread: https://cardano.stackexchange.com/questions/722/general-approach-for-allowing-multiple-smart-contract-transactions-per-block/2407#2407
I'm glad you've asked a new question about it, since I still haven't gotten a straight answer either.
Mitchell Turner
CC BY-SA 4.0
2021-08-26T18:52:03.013Z
Maybe I'm misunderstanding what people mean by "access control". Is Marek Mahut's answer what you were looking for?
Mitchell Turner
<smart-contract><utxo><eutxo>
How is access control managed with smart contracts in (e)UTXO?
# How is access control managed with smart contracts in (e)UTXO?

(Asked by: username_0 on 2021-08-26)

I've seen Charles mention this a little bit in some of his videos. He sort of laughs it off like the answer is obvious, but I'm not deep into the technicals. I also had an Ethereum developer bring it up, so I tried to do my own research and could not find the answer. Maybe it's so obvious that it doesn't really require a technical answer, but I'm here for a response either way. Specifically, the Eth dev said:

"Unspent outputs is the issue. Change addresses and smart contract interaction just doesn't vibe. This is exactly why ethereum is account based. Because it's the only rational way to do smart contract interaction."

Now, obviously there are many dapps from many devs running on the testnet right now, so I'm wondering what the technical rebuttal would be to this concern.

Thanks for all your contribution to the Cardano community!

**Tags:** smart-contract, utxo, eutxo
> **Comments:**
> **username_1**: I'm interested in this too. Here is another similar thread: https://cardano.stackexchange.com/questions/722/general-approach-for-allowing-multiple-smart-contract-transactions-per-block/2407#2407 I'm glad you've asked a new question about it, since I still haven't gotten a straight answer either.  
> **username_1**: Maybe I'm misunderstanding what people mean by "access control". Is Marek Mahut's answer what you were looking for?  

---

## 1 answers

### Answer by username_2 on 2021-08-26. Score: 1

If you think about it, your smart contact is attached to a specific UTXO. And somehow, in multi user environment, we need to distinguish the true smart contract output from other outputs that might also include this smart contact.

And the way we do this is to put an specific NFT on the output. Because an NFT can only exist once therefore is unique, there can only be one UTxO at the script address that holds the NFT and thus identities your smart contact.

This [article](https://medium.com/dcspark/every-eutxo-dapp-will-use-nfts-and-heres-why-fd87e6a8c9a6) from Robert Kornacki explains it in details, mostly:

> (...) dApp UTXOs having no in-built uniqueness property which make
> them clearly and reliably identifiable from others. This can be
> potentially capitalized on by bad actors, or may simply cause problems
> due to bad protocol design of new devs who are just getting their
> bearings. This clearly is a major issue that must be addressed,
> however we luckily have a great innovation which tackles this problem
> precisely, NFTs.
>
> (...) Because each NFT can only be created once and UTXOs have the ability
> to hold tokens, this means that if we put an NFT inside of the UTXO of
> the dApp we are deploying we can guarantee that no one else can do the
> same. The NFT acts as an unforgable unique identifier that makes it
> trivial for anyone and everyone to see which UTXO is the true
> deployment of the protocol. Each dApp frontend must merely save the
> currency ID of the NFT in order to be able to use it to verify that
> any UTXO it finds at the smart contract address has the correct NFT
> inside. If the UTXO does not, it is treated as invalid and ignored. It
> does not matter whether the invalid UTXO was created by mistake or by
> a bad actor on purpose, it is not the correct UTXO that we are looking
> for and thus filtered out. To ensure that the uniqueness property is
> forever held, the smart contract tied to the UTXO must specify that
> the NFT is never allowed to leave the dApp. In other words, every time
> someone spends the dApp UTXO, the NFT must be held in an output that
> is also locked by the same dApp smart contract (this technically
> changes in the context of dApp updates, but we can skip over that for
> now). This NFT preservation check is the only code required to
> guarantee the uniqueness property of the dApp. If this check is not in
> place then it may be possible for a bad actor to steal the NFT and put
> it in his deployment, thereby destroying all guarantees we had
> originally.


---

