Dominant assurance contract

[ProgramCrafter]

Summary

Create contract that implements dominant assurance payments.

Context

DACs can incentivize people to support project initiatives: if the target amount is not reached, everyone who supported project gets a bonus, and otherwise the project is built benefitting everyone.

Note: this footstep doesn't include a social platform to check reputation of those who proposed project.

Goals

• Create FunC contract or system of contracts implementing DACs

Deliverables

• Create contract with tests
• Publish the contract under MIT license

Definition of Done

• Contract created
• Tests created
• Contract published

Estimate suggested reward

• Standard TON Footstep NFT
• 450$ in TON

Total: 450$

Oriental Release Date

In 2 weeks after approval.

[delovoyhomie]

I studied the work of this contract. It's really useful and not quite complicated in my opinion.

@Gusarich, @Naltox, what do you think?

[aSpite]

I have studied the DAC idea and would like to develop this contract if it is approved.

[alirezatabatabaeian]

Hi there
This project involves two main sections:

• Investment Part
• Post-Campaign Part

I've just done the first part HERE but not tested yet.
You can reach me through My Telegram Account and have a discussion about the project.

[ProgramCrafter]

Hi @alirezatabatabaeian! I'm grateful for your contribution, though I have to note that @aSpite volunteered to do this task first. Also, your contract isn't yet published under MIT license.

[delovoyhomie]

I needed time to study the mechanics of the contract's operation, and it turned out to be really interesting. This material will be useful for learning purposes and may also be applicable in product projects.

[hitaspdotnet]

I like to implement this contract in Tact today. If needed.

[delovoyhomie]

@howardpen9, actually, I doubt the optimization of the solution on Tact. What do you think?

[aSpite]

@delovoyhomie

I hope if the idea of writing this contract the Tact is approved, the reward will be chosen fairly, taking into account the difference in complexity in the languages, as well as the fact that there will be a ready-made solution on FunC and Blueprint tests (I plan to publish the contract today).

[aSpite]

Contract and tests are ready: https://github.com/aSpite/dominant-assurance-contract

Wallet: EQDKbjIcfM6ezt8KjKJJLshZJJSqX7XOA4ff-W72r5gqPrHF

[krigga]

@aSpite having done a quick review of the code, I have the following suggestions:

• https://github.com/aSpite/dominant-assurance-contract/blob/879b3cb59d2f72affe54ee1fc3ab9332767371ce/contracts/assurer.fc#L150 it is better to force workchain == 0 for example and then use only the hash part of the address as the key (256 bits)
• https://github.com/aSpite/dominant-assurance-contract/blob/879b3cb59d2f72affe54ee1fc3ab9332767371ce/contracts/assurer.fc#L114 this need not be stored and should just be calculated where needed on the spot

[aSpite]

@krigga ,

1. The dictionary is used for sending transactions, so it will be more expensive to collect the address from the hash each time than if you immediately receive a slice with the address.

2. Due to inaccuracy in calculations, goal will not be accurately calculated, so I store what the user passed so that the getter gives exactly the number that was passed.

[delovoyhomie]

Rewards sent Thank you for the contribution.

• https://tonscan.org/tx/53TX15YO_2knjjAGzWKd7675KqMCztH2yrNdUsHvd8I=

Questbook proposal