@fabsltsa. Is it allowed. I thought many of the users have commented already on this project so It would be conflicting. Thanks for suggesting this I will update this post only then.
I donāt see what would be the issue with that if you notify that the entry changed hence the comment section current state.
But of course always better to ask @WindsOfChange92 just in case 
@Nahidbanu .Yes the previous project was dead. Now we are up with an new Idea. 
Give us some alpha about the other project 
@fabsltsa . I have updated the post. You can go through it and let us know how you feel about the idea. 
1 Like
Itās a good idea. Even for people moving tokens between their own wallets. If they see that they donāt get tx to sign on the recipient one, they can quickly go back to the first wallet and cancel the transaction.
Maybe you could add a small delay between the signature of the first wallet and the transaction arriving on the second wallet. So those users moving funds around have the time to switch wallet. Theyāll then see if the transaction is coming to their wallet or not.
Will you have time to push it on mainnet for June?
1 Like
@fabsltsa . Thanks for the compliment and going through the post. I think you are the first one . So there would be time for both the parties to sign the transaction. once both of them have signed then only the transaction will happen otherwise it will be reverted. also if there is a signature mismatch then also it will get reverted. The flow is like the user Initiates the transaction by signing it and then it will be visible to the recipient. after the recipient signed that and allow that he is the receiver and with the specified address then only the sender will send the transaction to the blockchain. also when you are doing a transaction you donāt usually see what you are signing. by leveraging EIP 712 we are able to show that also to the user.
Yes we will be good to go for pushing it to mainnet by June as our smart contract are almost completed and ready to be deployed on testnet for testing.
I was referring to those scammers sending 0.0000001 trx on your account after you make a transfer from a wallet that got the same 3-4 last digits.
The goal is that next time you want to send fund to your other wallet, you might copy the wrong address and send funds to them.
If you send funds to them, theyāll sign and get those. But if you have letās say 20-30 minutes to cancel the transaction before the counterparty can sign it, then you can avoid the mistake.
1 Like
Maybe it could be an option.
Letās say you want to buy something and you have to send funds directly, then there is no delay. But could add a button 15 min and a 30 min delay. For those who have time to review the transaction and scare to input a wrong wallet controlled by a malicious actor.
1 Like
This is a nice initiative which can save investors from becoming victims of sending funds to wrong addresses but where Iām not comfortable with is in the quoted part where you say that āthe sender signs a digital proposal using their private key.ā Can you explain further what you mean by that. Thank you
2 Likes
@fabsltsa . Ohh my bad, completely got your point. nice observation. Yes we can keep those delays before it reaches to the receiver to prevent it from such scam however the user will not like that as it takes much time but itās for their own security. also EIP 712 will help to address the issue. Implementing EIP-712 The details they are signing will be visible but if the scammer is trying to replicate the address with 3-4 last digits same then it would be difficult to identify there as well. Thanks for pointing this out. I think we can add one more feature that analyse the user sending history and find similar address if the scammer tries to replicate the address with last 3-4 digits same or other checks.
2 Likes
Thanks @Youngyuppie . Okay so the sender will sign the encoded function which they will be calling with all the parameters like recipient , amount and token address. then It will be sent to the receiver and after reviewing the details they will do the same. once both of them sign then the sender can trigger the smart contract which will then decode both the signature and verify the same address and same amount are signed by both the sender and receiver. if there is any difference then It would revert the transaction.
1 Like
I was questioning the whereabouts of the dev a while ago cause the initial offering was quite mute with barely 0 details, seeing you tweaked your initial project to an entirely new one seems satisfying yet tricky.
Welcome to Season 6, from my read I can clearly deduce that The HandShake project seems to address crucial pain points in token transfers by introducing a double confirmation process, flexibility in gas payments, and leveraging EIP-712 for enhanced security and clarity. This is a first for me, and Iād like clarity on how this solution would be hassle-free, so with that being said, Iāve a few questions;
How does the HandShake Protocol handle scenarios where one party disagrees with the transaction details after the initial agreement?
Could you elaborate on the criteria for selecting DeFi platforms for integration post-hackathon and how you plan to approach these integrations?
2 Likes
@manfred_jr, thank you again for the warm welcome 
. Iām more than happy to address your questions!
- If there is a disagreement between the parties, the transaction will not proceed. Such disagreements might arise if, for example, the amount being sent does not match the previously agreed-upon sum from their discussions. Essentially, both parties must come to a mutual understanding or, to use an analogy, āshake handsā on the terms for the transaction to go forward.
- We will select DeFi platforms based on the transactional value that occurs within each platform. We will evaluate the necessity of integrating a handshake mechanism. We can demonstrate these integrations on testnets first. Following this, we can approach the platforms by showcasing the value these integrations provide.
2 Likes
Once again you are welcome to the Hackathon, please I will like for you to tell me about all the challenges your team went through in the making of the core features, thank you
1 Like
Thank you for welcoming us to the Hackathon! Here are the key challenges our team encountered while developing our project:
- Implementing EIP-712: We faced difficulties integrating EIP-712 due to its complexity, striving to make transactions secure yet user-friendly.
- Smart Contract Security: Ensuring our smart contracts were secure involved extensive testing to prevent vulnerabilities.
- User Interface Design: Achieving a balance between functionality and simplicity in our UI required multiple design iterations.
- Optimizing Transaction Costs: We worked on minimizing blockchain transaction fees by optimizing our smart contract code.
2 Likes
Ensuring safe and secure token transactions is paramount in the world of blockchain and the HandShake focus on providing a double-confirmation step between the sender and recipient adds an extra layer of security and peace of mind which I believe can increase adoption of blockchain transactions.
I have this question for you
How will you handle situations where there are discrepancies or disagreements between the sender and recipient during the confirmation process?
2 Likes
hello @Chizz . these situations are bound to come. we donāt need to handle those situation there might me something conflicting between the sender and the receiver thatās why they would have disagreements. If the transaction is declined then the transaction will never be sent to the smart contract. the sender can again create a different proposal as per their mutual understandings.
1 Like
I presume @Prince-Onscolo @Nweke-nature1.com and the likes already got you covered on this.
3 Likes
Itās reassuring to know that disagreements are handled gracefully within the HandShake Protocol, ensuring that transactions proceed only when both parties are in mutual agreement. This emphasizes the importance of clear communication and consensus in the token transfer process.
Regarding the selection of DeFi platforms, focusing on transactional value as a criterion makes sense for prioritizing integration efforts. Demonstrating the value proposition through testnet showcases before approaching platforms for integration is a strategic approach. Have you identified specific DeFi platforms that align well with HandShakeās objectives, or are you open to exploring a variety of platforms based on their transactional volume?
1 Like