A generic multi-purpose contract for easy DApp development

Feature Request
1

Here’s a proposal for a generic multi use case contract that could be used in various DApp designs.
The purpose is to make DApp development more accessible to developers not familiar with either C++ or the specifics the BVM itself.


Would be great to get some feedback from the core team if this makes sense at all and what is or what isn’t possible.

In the proposed contract, developers can define some specifics of its behaviour through variables which they define at the time of on chain deployment of the .wasm file.

The Dapp interface and other components would then have to be build around these generic capabilities and limitations.


Constants to be defined at .wasm file deployment:
n_char: integer
ca_id: integer
fee_amount: integer
fee_handling_option: integer [0 to 2]
vault_cid: string

Basic functionalities:

  1. A public method to review the parameters used at deployment.

  2. A public “submit” method: a string of up to {n_char} characters gets submitted and stored on chain.

  3. A public “retrieve” method: returns all previously submitted strings (either all or starting at a given block height)

  4. An optional fee paid in a CA when using the “submit” method:
    With a simple logic as follows
    If ca_id < 0, no fee is needed (apart from the miners fee)
    If ca_id >= 0, a fee of {fee_amount} in the CA with ID {ca_id} is charged for each use of the “submit” method

  5. Options for what to do with the fees:
    if fee_handling_option == 0:
    the fees get send to a vault contract/vault account defined by {vault_cid}
    if fee_handling_option == 1:
    the fees can get withdrawn via a special method only available to the contract admin.
    fee_handling_option == 2:
    the fees are directly diverted to the Black Hole (burn contract)




→ The idea is that developers using this contract have a range of options of how they want to define the contract behaviour, without having to deep dive into the BVM.

There might be other useful functionalities that could be incorporated in such a contract. It should be imperative to keep it very generic, while giving a range of options at the time of deployment.

What are your thoughts on the feasibility and usefulness ?
Is the needed work justified (Beam Core team dev time)?
Are the above functionalities reasonable and well enough defined?
Are there other functionalities that should be added?

2 Likes