<p>The transaction size is limited. So your list cannot grow too large. But assuming you stay within these constraints, you can achieve what you want by (i) parametrising your validator with a type that contains the currency symbol of the needed token and then (ii) checking in your validator if the token with this currency symbol is in the inputs. Additionally you would check that the list of hashes (which you would store in the datum) is only appended and not altered.</p>
<p>With the Vasil hard fork in June, you can have another approach to (ii). You could add the UTxO that contains the token as a reference input and check in the validator that (a) the reference input contains the token and (b) that the transaction is signed by the holder of this reference UTxO.</p>
<p>Edit:</p>
<p>If you want a solution without smart contracts you could indeed use the metadata but it would also mean that the list update is controlled by a central party (which would be you). A possible design would be the following one:</p>
<ul>
<li>The location of the list is the metadata of the most recent transaction containing a specific token that you own. Let's call this token the list-NFT.</li>
<li>The users that want to append the list make a transaction to your wallet address. This transaction contains in its metadata the entry to be appended. The transaction would also contain a specific token that proves that the user has the right to append the list.</li>
<li>You have a service running that regularly filters the payments to your wallet address, verifies the presence of the token, and makes a transaction containing the list-NFT and the appended list.</li>
</ul>

CC BY-SA 4.0
2022-05-05T10:32:45.453Z
thank you for information on this, i appreciate it. I was thinking users could all add entries to the same metadata key and true entries could be found by querying the blockchain with some off chain logic to confirm the person owned the nft at that time. Smart contracts seem like a better option though.
kannastor
CC BY-SA 4.0
2022-05-05T11:07:50.880Z
Ok, I understand. I edited the answer.
Jey
CC BY-SA 4.0
2022-05-04T18:57:48.040Z
2022-05-05T11:06:40.747Z
2022-05-05T11:06:40.747Z
Jey
<p>I think there are two kinds of solutions. The first is the most cost efficient and is focused on offchain indexing of the database, anybody can do it but there is no logic onchain. The second one is where you use plutus (and especially version 2, hard fork will be 29 of june and plutus will be fully available 1 epoch later).</p>
<p>For the former you can just let holders of a token create metadata transaction that contain atleast x tokens y. Then with a DB-sync instance anyone can index the latest state of the database. You even can introduce some overriding rules.</p>
<p>The second solution could be to use the reference capabilities of plutus V2. With the upcoming hard fork referencing outputs will be possible. With this you could make a database sitting on an script address where each UTxO is an entry. You could use this database in the future if needed. To prevent false entries you could create a minting policy which created some validity token if x amount of token are present. The cool thing about this solution is that the data is pretty localized and the present state is well defined and easy to obtain.</p>
<p>Hope this helps and I would love to see you make one of these!</p>

CC BY-SA 4.0
2022-05-05T16:14:06.167Z
2022-05-05T16:14:06.167Z
Fermat
<p>I want to construct public lists that can be altered by people who own a specific token.</p>
<p>Is there a way I can group data together into an array like structure and allow users to append to it?</p>
<p>I understand metadata will play a fundamental role here, and I guess it will have something to do with the wallet updating the arrays digital signature.</p>

CC BY-SA 4.0
2022-05-04T18:08:42.950Z
How large is this array going to be and what shall it contain ?
Jey
CC BY-SA 4.0
2022-05-04T18:41:15.947Z
It will contain IPFS hashes of files, the size could vary but possibly up to 500 entries
kannastor
CC BY-SA 4.0
2022-05-05T09:42:27.623Z
What function does the array serve? Does it only serve information or do you want to use it with some logic?
Fermat
CC BY-SA 4.0
2022-05-05T10:25:31.770Z
purely as an immutable information log that can be queried using blockfrost for example
kannastor
CC BY-SA 4.0
2022-05-05T15:05:43.873Z
Do you want it to be an append only list?
Fermat
<nft><transaction><native-assets><metadata><transaction-metadata>
How can I allow users to update a public array of data based on whether they own a token or not?
# How can I allow users to update a public array of data based on whether they own a token or not?

(Asked by: username_0 on 2022-05-04)

I want to construct public lists that can be altered by people who own a specific token.

Is there a way I can group data together into an array like structure and allow users to append to it?

I understand metadata will play a fundamental role here, and I guess it will have something to do with the wallet updating the arrays digital signature.

**Tags:** nft, transaction, native-assets, metadata, transaction-metadata
> **Comments:**
> **username_1**: How large is this array going to be and what shall it contain ?  
> **username_0**: It will contain IPFS hashes of files, the size could vary but possibly up to 500 entries  
> **username_2**: What function does the array serve? Does it only serve information or do you want to use it with some logic?  
> **username_0**: purely as an immutable information log that can be queried using blockfrost for example  
> **username_2**: Do you want it to be an append only list?  

---

## 2 answers

### Answer by username_1 on 2022-05-04. Score: 1

The transaction size is limited. So your list cannot grow too large. But assuming you stay within these constraints, you can achieve what you want by (i) parametrising your validator with a type that contains the currency symbol of the needed token and then (ii) checking in your validator if the token with this currency symbol is in the inputs. Additionally you would check that the list of hashes (which you would store in the datum) is only appended and not altered.

With the Vasil hard fork in June, you can have another approach to (ii). You could add the UTxO that contains the token as a reference input and check in the validator that (a) the reference input contains the token and (b) that the transaction is signed by the holder of this reference UTxO.

Edit:

If you want a solution without smart contracts you could indeed use the metadata but it would also mean that the list update is controlled by a central party (which would be you). A possible design would be the following one:

* The location of the list is the metadata of the most recent transaction containing a specific token that you own. Let's call this token the list-NFT.
* The users that want to append the list make a transaction to your wallet address. This transaction contains in its metadata the entry to be appended. The transaction would also contain a specific token that proves that the user has the right to append the list.
* You have a service running that regularly filters the payments to your wallet address, verifies the presence of the token, and makes a transaction containing the list-NFT and the appended list.

> **Comments:**
> **username_0**: thank you for information on this, i appreciate it. I was thinking users could all add entries to the same metadata key and true entries could be found by querying the blockchain with some off chain logic to confirm the person owned the nft at that time. Smart contracts seem like a better option though.  
> **username_1**: Ok, I understand. I edited the answer.  

---

### Answer by username_2 on 2022-05-05. Score: 0

I think there are two kinds of solutions. The first is the most cost efficient and is focused on offchain indexing of the database, anybody can do it but there is no logic onchain. The second one is where you use plutus (and especially version 2, hard fork will be 29 of june and plutus will be fully available 1 epoch later).

For the former you can just let holders of a token create metadata transaction that contain atleast x tokens y. Then with a DB-sync instance anyone can index the latest state of the database. You even can introduce some overriding rules.

The second solution could be to use the reference capabilities of plutus V2. With the upcoming hard fork referencing outputs will be possible. With this you could make a database sitting on an script address where each UTxO is an entry. You could use this database in the future if needed. To prevent false entries you could create a minting policy which created some validity token if x amount of token are present. The cool thing about this solution is that the data is pretty localized and the present state is well defined and easy to obtain.

Hope this helps and I would love to see you make one of these!


---

