Dynamic number of participants in smart contracts

Question

Sample use case: For a DAO smart contract, we would like to add members to a DAO over time. What is the best way to ensure that this can be done. Because in Marlowe the "PARTY" to the contract is defined at the beginning.

One solution can be to issue a certain number of role tokens in the contract. And over a period of time, to distribute these role tokens to DAO participants. But then the question, comes is how do we create multiple role tokens in marlowe contract, for a single "Party". In this case then we create a role called "DAO member" and issue say 1000 tokens for this role.

Any help appreciated ?

Answer 1

Your approach of pre-minting role tokens would work, but with a couple of limitations:

1. Each role token should probably have a unique name ("DAO Member 1", "DAO Member 2", etc.) so that participants can be separately identified in the Marlowe contract. Otherwise, it would be difficult to prevent the same token holder from voting multiple times.
2. There is a practical limit to how many roles a Marlowe contract can have. The history of choices made by the contract's roles is stored on-chain in the Plutus Datum of the contract's eUTxO. The Cardano network protocol limits how large a transaction can be, so that effectively limits the number of roles that could participate in a contract. The precise limit depends upon the length of the role-token names and other factors.
3. Contracts involving many roles tends to be very large. To fit such contracts on the Cardano blockchain, one needs to use a technique called Merkleization, which is supported by the Marlowe language and command-line tool. Using Merleization for a DAO might involve writing some moderately complex off-chain code to manage the Merkleized continuations of the contract.

Overall, Marlowe contracts aren't well suited for use as a DAO. It can work for some use cases for small DAO's, but not for arbitrarily large DAOs. For large DAOs, a Plutus solution or a hybrid Plutus+Marlowe solution would probably be better.

Answer 2

I've never used marlowe before, so I'm not sure the following solution can be implemented in marlowe, but this is certainly something possible.

in theory, you could store a list of "DAO members" on the smart contract's datum, however, practically this isn't possible due to the protocol's transaction size limit.

what you can do is implement a minting policy that mints your "DaoMember" coins (or NFTs) and then require that token to be present in the transaction that interacts with your DAO smart contract.

if the "DaoMember" token is present then the user has access to the member-level smart contract functionalities, if not we treat the user as a regular one with restricted access.

in all this the minting policy is open to mint/burns