Plutus Research: Common parameter data type

[HinsonSIDAN]

This is for gather a list of common parameter data type for implementation of issue 4. A few examples are below:

Integer
String
CurrencySymbol
TokenName
AssetClass
POSIXTime
PaymentPubKeyHash
PubKeyHash

@aleeusgr Please help to explore current contracts implemented by Gimbalabs to check if there is any missing from above

[aleeusgr]

Motivation

In the next release, we aim to supply users with a set of prepared smart contracts. So we have to decide:

1. How many contracts to supply?
2. What contracts do we supply?
3. Exactly what parameters can be changed for each contract?

A challenge to consider is that web-API does not provide specific data types that Plutus scripts are using, therefore we have to convert them. Not all parameters are created equally: for some, their data type can be easily inferred, and probably there are parameters that are impossible to use in this way.

Therefore our decision has to be balanced between "how useful a given parameterized smart contract will be to the end user?" and "how difficult it is to implement?"

[aleeusgr]

I think ultimately we should aim to support Gimbalabs Project Treasury, which has two smart contracts - Treasury and Bounty.

An alternative could be a smart contract that has potential for being used often, and has a set of parameters that are easy to work with.

[aleeusgr]

data FaucetParams = FaucetParams { accessTokenSymbol :: !CurrencySymbol , accessTokenName :: !TokenName , faucetTokenSymbol :: !CurrencySymbol , faucetTokenName :: !TokenName , withdrawalAmount` :: !Integer } deriving (Pr.Eq, Pr.Ord, Show, Generic, ToJSON, FromJSON, ToSchema)

[HinsonSIDAN]

How many contracts to supply? --> Now user can supply their own plutus script for the service (but limited to one parameter only)

What contracts do we supply? --> Their own, for both minting policy & validator (with both V1 V2 supported)

Exactly what parameters can be changed for each contract? --> Any custom parameter, but limited to one only at the moment

[HinsonSIDAN]

A quick design choice has been made, where parameter data type is handled in JSON body crafting process. So this issue turns out to be about documentation guide on know-how instead of implementing on Haskell lib

[HinsonSIDAN]

Closing it for now as we have covered most param types in docs.