Handling Disputes at Kickback
Currently Kickback is heavily relying on the assumption that both event organisers and participants work cooperatively. This works fine when Kickback is used among trusted event organisers with participants who understand the rule of the service well.
As more events start using our services, we cannot expect everybody to follow the rules on their good will and need to provide more strict rules or incentives at smart contract level to prevent from both intentional/accidental misbehaviours.
In this article, I will first describe the different actors involved, then list of disputes with associated risks. The description of each dispute includes the rational behind the behaviour as well as potential solution options.
- Operator = Kickback team
- Event Organiser
- Contract owner = Person who deployed the contract (usually Operator or Event organiser). The owner can change metadata, up/down participant limit, and grant/revoke admin rights.
- Admin = People who received a right to check in attendees (and being able to finalise the attendees). They may or may not be participants themselves
- Participants (people who did RSVP)
- Attendees (participants who did RSVP and attended the event)
- Non attendees (participants who did RSVP and attended the event)
- Waitlist/Crashers (participants who did not RSVP and attended the event)
Life cycle of Kickback event
- Start of the event = The event starts when its event contract is deployed from our admin panel.
- RSVP = When participants RSVP to the event. Currently there is no way to stop RSVP before the capacity fills up. The only way to work around is for admin to lower the capacity down to the number of RSVPed participants.
- Finalise = This is a period when one of admins press
finalizebutton. After the event, no one can RSVP the event nor marked as attended.
- Withdraw = After the Finalise, all participants can withdraw their ETH
- Likelihood = How likely would this happen?
- Impact = Would this affect entire event or only a few participants?
- Severarily = What is the size of financial loss?
- Contract owner does not mark anyone [L:low, I:high, S:high]
- Contract owner marks non attendees [L:mid, I:low, S:low]
- Contract owner does not mark attendees [L:high, I:mid, S:mid]
- Contract owner changes event details (date/time) which prevents participants from attending [L:mid, I:high:high]
Description of the disputes
1. Contract owner does not mark anyone
A contract owner deploys an event and RSVP him/herself. Participants RSVP and go to the event but the event is fake or not organised by the contract owner. All attendees apart from the contract owner lose all their ETH.
The intention is 100 % malicious by the contract owner. One can easily fake events by simply copying & pasting existing events or make up completely.
During DevCon4 multiple event aggregation page popped up some of which were copying event details from other sites (and we have no idea whether these aggregated pages had some consent from event organisers). These aggregation sites are harmless as they cannot collect money. However, people could abuse Kickback to setup copy events , collect ETH and run away.
[1.1] Have certain duration of “dispute period” (eg: 1 week) before between
finalize period to operators.
When operator find out that this was a fake event, then operator enforces the rule to cancel the event so that all participants can withdraw the exact ETH amount they have put. To enable that, smart contract needs to be changed to allow operators to be able to cancel the event.
[1.2] Do not allow new users to use Kickback unless referred from existing event organisers.
If event organisers misbehave, then kick out both the organiser and the one who referred out of the system. We could even make this process more elaborate by introducing Token Curated Registry with stake slashing among organisers, though such system only help preventing issues and won’t help recovering the Eth once the incident happened.
2. Contract owner marks non attendees
Description and Rational
This could be either intentional or accidental. It will be accidental if admins press “mark as attend” by mistake.
It will be intentional in the following case.
- Admins were tracking attendance off chain (eg: using piece of paper) but lost the information, hence marked everyone to avoid complaint.
- One of non attendees are the friend of admins and asked admins to mark themselves checked to avoid losing ETH.
[2.1] Attendees must provide their digital signature.
We could create a QR code system to ask participants to sign signature and download it as a QR code. Admins can only mark the person if they scan the QR code and can recover the attendees’ ETH address from the signature.
This will prevent the case of admins mark everybody but cannot prevent the case for friends of admins, as they can send their signature to admin via email without presenting.
3. Contract owner does not mark attendees
Description and rational
This case happens often when admins are not present when attendees come to the venue (often because attendees arrived after the event has started)
[3.1] Make check in timing very explicit (eg: within 30 min before the event starts).
This requires no smart contract change (or add explicit
check-in period and do not allow admins to check in before/after the period). Making smart contract dependent on small time window (hours, not days) could be potentially problematic when gas price is really high or network is super congested which happened multiple times in the past.
- 2016 Sep: DevCon2 Shanghai attack where resource usage was too high to make any transaction for 3 days.
- 2017 July: Status.im ICO when many transaction pended over days (or never confirmed).
- 2017 Oct: pre hard fork ice age when each transaction took days.
- 2017 Dec: CryptoKitties network congestion made any transaction very expensive for weeks.
- 2018 June: F-coin spamming network made gas price to surge to 100gwei for over a week.
[3.2] Provide one time code as
Proof of attendance
Organisers can provide some sort of “secret code” at the venue which participants scan and self-sign , which Uport team did during DevCon3.
This can be potentially gamed if the secret code gets on social media.
Having said that there are less incentive for attendees to do so at Kickback as revealing secrets decreases their own payout.
[3.3] Take selfie with one time code and provide it during dispute period.
This is the reverse of 3.2. Attendees submits the code during dispute period with their selfie photo with the code provided during the event (eg: QR code at the event). This will prevent the one time code leaking issue of 3.2 though the verification must happen manually hence more overload to event organisers and admins.
[3.4] Use some geolocation or IoT as “Proof of address”.
I often receive this suggestion. Geolocation integration seems makes sense but we need to bear in mind that browser location information is relatively easy to manipulate (I’ve been curious if FOAM can be used to solve this issue, but wasn’t clear when I had a chat with the team back in 2018 May when they were at Ethereum London).
Another solution would be to create a Raspberry Pi based wifi hotspot which only allows attendees in the wifi range to be able to access local web server embedded in the Pi to act as admin. This would potentially allow Kickback to be used in a lot bigger venues or parties with no / little check in required.
4. Contract owner changes event details (date/time) which prevents participants from attending
Description and rational
This could happen regularly as venue detail (such as location and date) changes from time to time.
[4.1] Do not allow admins to update metadata but only allow them to cancel the event.
The smart contract should have “Draft” period of which contract owner can edit metadata, but do not allow metadata to be changed once the event registration starts. If the event detail changes, organisers can only cancel the event. Participants have to re-register.
[4.2] Make RSVP cancelable when some of the event details have changed.
When metadata detail has changed, allow participants to be able to cancel their RSVP for the limited time period.
Unique aspects of handling events via smart contract.
I will welcome any feedback or more creative solutions to tackle these dispute problems. When you do suggest, please also take into account some unique aspects of handling events via smart contract.
- It is a lot more difficult to handle dispute resolution in a decentralised manner among participants of a specific event because the event organisers can sybil attack his/her own event by creating lots of fake accounts.
- Having said that, Kickback smart contracts have all past attendee’s Ethereum address, so it is technically possible to do some voting among entire Kickback community (and sybil attacking the entire community is harder than sybil attacking an event). It is differently story whether our members actually participate such a voting though.
- Any sort of self sign in at the event venue is relatively challenging because many people still RSVP on desktop using Metamask (unless forcing users to only use self sovereign identity services such as uPort). A solution to let users to print out QR code may be preferred from UX point of view as it is common approach among more traditional event services.
- RSVP with anonymity may not be feasible to many events as venue security often requires participant’s identity.
I would love to have feedback about other dispute vectors as well as more creative solutions. Please feel free to discuss at the comment of this article, raise a KIP, or chat with us on our telegram channel!