Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HIP 133: Bridging Gap for Anti-Gaming Measures Phase 2 #1087

Merged
merged 11 commits into from
Oct 8, 2024
64 changes: 64 additions & 0 deletions hip-xxx-bridging-gap-for-anti-gaming-measures-phase2
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
HIP-xxx - Bridging Gap for Anti-Gaming Measures Phase2
abhay marked this conversation as resolved.
Show resolved Hide resolved

Author(s): - Author(s): [Fizzy99](https://github.com/mrfizzy99), [Rendell](https://github.com/RendellD85)
mrfizzy99 marked this conversation as resolved.
Show resolved Hide resolved
Start Date: 2024-09-05
Category: Economic, Technical
Original HIP PR:
Tracking Issue:
Voting Requirements: veMOBILE Holder
mrfizzy99 marked this conversation as resolved.
Show resolved Hide resolved

---

## Summary

This HIP aims to further the refinement of HIP-131, and will further extend the scope of HIP-131 to cover all remaining areas that were not previously included (such as C** areas), along with other tweaks and changes.


## Related Prior HIPs
* [HIP 103: MOBILE Oracle Hex Boosting](./0103-oracle-hex-boosting.md)
* [HIP 118: Verification Mapping for MOBILE Network](./0118-verification-mapping.md)
* [HIP 125: Temporary Anti-Gaming Measures For Boosted Hexes](./0125-temporary-anti-gaming-measures-for-boosted-hexes.md)
* [HIP 131: HIP-131: Bridging Gap Between Verification Mappers and Anti-Gaming Measures](./0131-bridging-gap-between-verification-mappers-and-anti-gaming-measures.md)


## Motivation

While we thought that 'C' footfall areas would be less utilized for gaming activities, we were wrong. Gamers have found refuge in C footfall areas as the first phase of HIP-131 was implemented. Our hopes that making a CDR requirement to activate PoC rewards becomes the norm for all location asserts.

## Stakeholders
* Deployers: This preserves POI hex rewards for legitimate and active coverage builders.
* Service Providers: This provides a temporary tool to prevent abuse of POI hexes, helping ensure these strategic regions have legitimate coverage and further improve implementation of HIP-118.


## Detailed Explanation

This HIP would enact the following:
- Extend the valid CDR requirement from HIP-131 from only applying to hotspots in Oracle Boosting Multiplier areas (A**, B**), to apply to all areas (A**, B**, and C**).
- Adjust the HIP-131 requirement (A**, B**, and C**) to require a valid CDR every 42 epochs.
- For Boosteed Service Provider locations, a valid CDR will be required every 7 epochs. If a invalid CDR is registered, it will invalidate the valid CDR. This will be left up to the Service provider to quality control what does or does not qualify.
mrfizzy99 marked this conversation as resolved.
Show resolved Hide resolved
- Extend the duration of HIP-131 (from 150 epochs) to last until both phases of HIP-118 are fully implemented and active.
- Allow HIP-118 (Verification Mapping for MOBILE Network) to utilize CDR information if the Server Provider chooses for all areas, including Serviuce Provider Boosted areas. 
mrfizzy99 marked this conversation as resolved.
Show resolved Hide resolved


## Drawbacks

Having a 42 epoch renewal may be viewed as counterintuitive, but this allows the network to filter out non-utilized hotspots from earning PoC for extended periods of time throughout the hotspot or radios lifetime.


## Unresolved Questions

None.


## Implementation

Nova Labs and Helium Mobile have agreed to the implementation of this proposal, which will be implemented immediately after passing a vote.
Mobile Oracles will report tagging of the hotspots for suspicious activity by the SPs. This off-chain data will record both tagging and untagging activities for the concerned hotspots. This data will be shared in a way that community applications can allow a deployer to understand concerned hotspots have been flagged.
Current SP has indicated they will use their existing support ticket system to manage deployers that feel they have been mistakenly identified as malicious, including an internal escalation procedure to help mitigate support tickets being left unaddressed indefinitely.

## Success Metrics

The desired outcome of this HIP is that Oracle Hex Boosted areas are deployed with mobile hotspots that provide high quality, usable cellular coverage for customers of the MOBILE network and attract potential SPs.
Measuring the success of this HIP will require ongoing collaboration with the SP to understand how many mobile hotspots are potentially flagged as malicious through community forums such as the mobile working group community.
Success of this HIP will be measured by the amount of discouragement of illegitimate deployments, and an increase of CDR data in legitimate hotspots.