Skip to content

Add Promotional Proof Transactions (PPT) documentation #39

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

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

adklempner
Copy link

This PR adds documentation for the Promotional Proof Transactions (PPT) feature, which enables new users to join the Status Network without needing to already possess tokens or pay gas fees. It includes a detailed explanation of how PPT works, its benefits, use cases, and integration with the existing Karma system. Also updates the karmic-tokenomics.md file to reference PPT as another way to earn Karma.

This PR adds documentation for the Promotional Proof Transactions (PPT) feature, which enables new users to join the Status Network without needing to already possess tokens or pay gas fees. It includes a detailed explanation of how PPT works, its benefits, use cases, and integration with the existing Karma system. Also updates the karmic-tokenomics.md file to reference PPT as another way to earn Karma.

The PPT system is designed to evolve through community governance:

- **Parameter Adjustments** – Karma holders can vote to modify which proofs are accepted and their relative reward values.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably Karma + SNT holders

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the goal is to get people to bridge + stake their SNT (or provide liquidity with it in the native DEX). in both cases they would earn Karma. so i think we can restrict it to Karma holders

Copy link
Contributor

@0xcyp 0xcyp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this definitely has value and should be part of the tokenomics.

only things unclear on my end: users will need to submit a proof of activity from other networks. how will the proof verification happen before giving Karma? onchain or offchain? if onchain, it means that the chain will have a gasless proof of activity verifier system and anyone can submit proofs to verify without paying gas. how do we prevent spam and DDoS attacks on this service?

@adklempner
Copy link
Author

this definitely has value and should be part of the tokenomics.

only things unclear on my end: users will need to submit a proof of activity from other networks. how will the proof verification happen before giving Karma? onchain or offchain? if onchain, it means that the chain will have a gasless proof of activity verifier system and anyone can submit proofs to verify without paying gas. how do we prevent spam and DDoS attacks on this service?

yeah definitely need to think through the spam angle. my initial thought is a hybrid approach:

  1. commit-reveal pattern - users first commit proof hashes offchain to a queue, then we batch verify onchain periodically. this limits the onchain load since we're not processing every proof immediately

  2. rate limiting by source - each L1 address can only submit proofs once per epoch (say 7 days). since they need genuine L1 activity to generate valid proofs, sybil attacks become expensive

  3. progressive verification tiers - start with lightweight proofs for basic karma (like "owned ENS for 6+ months") that are cheap to verify, require heavier proofs for larger karma grants

for the gasless part, we could have the verifier contract sponsored by the protocol treasury initially, with circuit breakers if submission rate spikes. once someone has karma from their first proof, subsequent proofs would require them to pay gas (since they now have transaction rights)

the nice thing about giving karma vs tokens is we can be more experimental - if someone games the system, they just get governance weight rather than extractable value. we can always adjust the parameters through governance if certain proof types get abused

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants