Challenges we ran intoįirst we implemented the backend with REST and the captcha as a popup. By adding a new campaign, protocol tokens are send to the contract, which pay the user. The Solve3Verifier checks (for now) if a contract is added as beta tester and if the validator of the proof is an actual legit validator.įor now only the owner can add the advertisment campaigns to the Solve3Verify contract. Both contracts check the validity of the proof before the actual logic is executed and the earned protocol token are send to the user. The destination smart contract must implement the Solve3Verify which interacts with the Solve3Verifier contract. Using this proof, the user is able to execute the function of the destination smart contract.
If the solution is valid, the backend sends a proof to the frontend. The backend validates the solution of the captcha.
Based on the signed message a captcha is created for the address of the signer. A handshake is performed and then the user signs the handshake. The frontend establishes a websocket connection to the backend server. The backend server, which is written in JavaScript, using nodejs, express and websockets. The JavaScript frontend module which loads the captcha data from the backend server and opens the captcha modal. On a high level, Solve3 consists of 3 components. By using this proof, the user is able to execute the smart contract function and earns protocol token. The user has to solve a captcha, which creates a proof. It combines captchas and advertising campaigns to give the user an additional incentive and enables the placement of ads in web3 applications. Solve3 is a captcha service for smart contracts.
With this project, we would like to counter that. For example as soon as an NFT sale starts, all items are sold. Often with general NFT sales, but also when you want to buy a ticket, or in web3 gaming. There are always situations in web3 space where bots are a problem.
0 kommentar(er)
