The SPARKN protocol is a Web3 project that aims to build a marketplace for anyone who wants to solve their problems or anyone who wants to help solve problems. As a first step, we have created the protocol. The details of how to use the protocol is up to the users. This team is a graduate of the Foundry Full Course on YouTube with $15,000 up for grabs!
Nowadays information is spread around the world in an incredible speed. However, in some isolated areas the information gaps are too substantial to overcome the challenges. One of the biggest challenges we noticed so far is: neither there are talented people nor incentives to create great ideas in some of these areas.
We found that there are many problems can be solved by the community in a more innovative and open way if things are done openly and smartly with adequate incentives.
Since its inception, Web3, or we can all it "blockchain industry", has been thriving, thanks in part to its inherent incentive structure. We believe that the underlying philosophy and values of Web3 can be applied more widely to address various problems.
Our belief is that the more problems we can solve using this technology, the more value we can generate. This, in turn, will allow more people to reap the benefits of Web3 and blockchain. Ultimately, this could lead to the widespread adoption of Web3, allowing it to become a mainstream technology
Because of this, we have created SPARKN.
SPARKN protocol is a Web3 project that aspires to create a marketplace for anyone looking to find solutions to their problems or eager to assist others in solving theirs.
As an initial step, we've developed the protocol without any limitations. The manner in which the protocol is used is entirely at the discretion of the users, allowing them to adapt it to their unique needs and preferences.
Any file except for the files in the above Scope.
The contracts in this repository are used as escrows for SPARKN users' assets on-chain. Our goal is to make sure assets on SPARKN are safe and transparent, no matter who is using it.
These contracts are responsible for the escrowing of users' funds and distributing them to the winners of the contests. We tried to keep things simple and safe.
All the contracts are sitting in the
src/ folder. These are the core contracts of the protocol.
The contracts are supposed to be deployed to any EVM-compatible chains.
There are mainly 3 roles in the protocol. Another role is the owner.
The graph below shows the structure of the contracts and their relationships in the protocol.
If a contest is created and funded, there is no way to refund. All the funds belong to the persons who wants to help solve the problem, we call them "supporters". And there is a certain assets-locking period of time in which no one except the organizer can call and distribute the funds to the winners.
This is the main entry point of the protocol.
It has several functions.
getProxyAddress()to get the address of the proxy even before its deployment.
This contract inherits the
Ownable contract from OpenZeppelin for access control. And it inherits the
EIP712 contract from OpenZeppelin for meta transaction.
_hashTypedDataV4 is used for function
This is a contract used as the logic contract of the proxy. It will not be used as a single contract, but it will be called through proxy as delegate calls.
Its functions are as follows:
distributefunction to distribute prizes to winners.
This is a proxy contract. It will be deployed by the factory contract. This contract is paired with every single contest in the protocol.
Tests are in the
test/ folder. More explanations about test cases can be found in the test folder's
These are known issues or designed by purpose.
See here for more known issues generated by the 4nalyz3r tool.
This sequence diagram shows how the protocol works considering the process of the contest with the roles in the protocol.
sequenceDiagram actor 1 as Owner actor S as Sponsor actor O as Organizer participant PF as ProxyFactory participant P as Proxy participant D as Distributior actor W as Winners actor RT as rescue requestor Note over 1,W: Contest Preparation Phase activate PF activate D 1->>PF: setContest() PF-->>S: getProxyAddress() S->>P: send erc20 token PF-->>O: getProxyAddress() O->>P: send erc20 token Note over PF,D: Wait for contest to reach close time Note over 1,W: Distribution Phase rect rgba(0, 255, 0, 0.1) alt Pattern 1: Distribute by organizer Note over O: When organizer is active to end the contest O->>PF: deployProxyAndDistribute() else Pattern 2: Distribute by signature Note over O: When organizer is active and wants to use meta tx O ->> 1: send signature 1->>PF: deployProxyAndDistributeBySignature() note over PF: signature validation is OK else Pattern 3: Distribute by owner Note over 1,W: Contest Expiration Phase Note over O: When organizer is not active Note over PF, D: And if contest is expired 1->>PF: deployProxyAndDistributeByOwner() end end PF->>P: deploy proxy and calls distribute() activate P P->>D: delegatecall distribute() P-xW: distribute erc20 token as prizes P-->>PF: Proxy address PF-->>O: Proxy address deactivate P rect rgba(0, 0, 255, 0.1) opt activate P Note over 1,W: Contest Expiration Phase Note over P: Proxy is deployed and token is distributed Note over P: If whitelisted tokens are sent by mistake 1->>PF: distributeByOwner() PF->>P: deploy proxy and calls distribute P->>D: delegatecall distribute() P-xRT: rescue erc20 token, send to rescue requestor end end deactivate PF deactivate P deactivate D Note over 1,W: Contest ends here
run a single test
forge test --mt <test_function_name>
run fuzz test
forge test --match-contract FuzzTestProxyFactory
see test coverage
forge deploy --network <network>
or deploy to local network
Format the codes