Add ERC: Social SBT #924
Open
Add ERC: Social SBT #924
+143
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
|
The commit da094e7 (as a parent of 3fa973d) contains errors. |
SamWilsn
reviewed
Apr 28, 2025
Comment on lines
+3
to
+4
| title: Social SBT | ||
| description: Social SBT, A Soul-Bound Token for DAO Governance |
Contributor
There was a problem hiding this comment.
Your title and description need some work. "Social SBT" gives no useful information about the token, and your description is mostly repeating your title or expanding SBT. Try to make your title unique and meaningful, and your description should expand on your title instead of simply repeating it.
| type: Standards Track | ||
| category: ERC | ||
| created: 2024-01-25 | ||
| --- |
Contributor
There was a problem hiding this comment.
Suggested change
| --- | |
| requires: 721 | |
| --- |
Comment on lines
+38
to
+86
| 1. **Minting Tokens** | ||
| - **Function**: mint() public override payable | ||
| - **Description**: The mint function MUST override the base [ERC-721](./eip-721) implementation to ensure compliance with SocialSBT’s non-transferability and single-token ownership per address. | ||
| - **Constraints**: | ||
| - The caller must pay the exact _price. | ||
| - Each address can own only one token. | ||
|
|
||
| 2. **Deleting Tokens** | ||
| - **Function**: deleteToken(uint256 tokenId) public | ||
| - **Description**: Allows token owners to permanently delete their tokens without refunds. | ||
| - **Constraints**: | ||
| - Caller must own the specified token. | ||
|
|
||
| 3. **Voting on Proposals** | ||
| - **Function**: vote(uint256 votingIndex_, bool choice_) public | ||
| - **Description**: Token holders can vote "yes" (true) or "no" (false) on proposals to adjust social points. | ||
| - **Constraints**: | ||
| - Caller must own a token. | ||
| - Each caller can vote only once per proposal. | ||
|
|
||
| 4. **Ending Voting** | ||
| - **Function**: endVoting(uint256 votingIndex_) public | ||
| - **Description**: Ends voting and adjusts points if the majority votes "yes." | ||
| - **Constraints**: | ||
| - Voting period must have expired. | ||
| - Proposal must be active. | ||
|
|
||
| 5. **Querying Token Points** | ||
| - **Function**: pointOf(uint256 tokenId) public view returns (uint256) | ||
| - **Description**: Retrieves the social points associated with a specified token. | ||
|
|
||
| 6. **Event Triggers** | ||
| - **NewVotingCreated**: Triggered when a voting proposal is created. | ||
| - **VoteEvent**: Triggered when a user casts a vote. | ||
| - **VotingEnd**: Triggered when voting ends. | ||
| - **PointUpdated**: Triggered when token points are adjusted. | ||
|
|
||
| 7. **Voting Struct** | ||
| - **votingIndex**: uint256 | ||
| - **name**: string | ||
| - **description**: string | ||
| - **tokenIndex**: uint256 | ||
| - **point**: uint256 | ||
| - **increase**: bool | ||
| - **yes**: uint256 | ||
| - **no**: uint256 | ||
| - **startDate**: uint256 | ||
| - **endDate**: uint256 | ||
| - **isActive**: bool |
Contributor
There was a problem hiding this comment.
I'd recommend using a solidity interface instead of writing it out in this form.
Comment on lines
+90
to
+100
| SocialSBT decouples governance power from token holdings by implementing a community-based governance system. This ensures fairness and prevents undue influence by high-point token holders. | ||
|
|
||
| Unlike traditional DAOs, where governance power is directly tied to the number of tokens held, SocialSBT enforces a **contribution-based governance model**. However, social points are **not automatically assigned** when a user contributes. Instead, members must perform valuable actions that prompt the community to initiate a voting process to recognize their efforts. This approach ensures that social points are **collectively decided and transparently adjusted** rather than arbitrarily awarded. | ||
|
|
||
| Here’s how SocialSBT mitigates whale attacks in practice: | ||
|
|
||
| 1. **Non-transferable tokens**: Since SocialSBT tokens cannot be bought or transferred, governance power cannot be acquired through market purchases. | ||
| 2. **Community-driven social point adjustments**: Social points are not automatically granted. Instead, a proposal must be initiated and approved by the DAO community for a member’s points to increase or decrease. | ||
| 3. **Contribution-based voting power**: Only members who provide meaningful contributions can gain governance influence, and these contributions must be recognized by the community through an **on-chain voting process**. | ||
|
|
||
| Because SocialSBT ensures that governance influence is directly linked to community engagement rather than wealth, whales cannot manipulate voting outcomes by simply acquiring tokens. This system reinforces democratic participation and aligns decision-making with the collective interests of the DAO. |
Contributor
There was a problem hiding this comment.
Most of this belongs in Motivation. The Rationale section should explain technical decisions made while writing the proposal, where the Motivation section justifies the proposal as a whole. My favourite analogy is:
Motivation: We need to build a shed because...
Rationale: We chose to paint the shed red because...
Comment on lines
+108
to
+129
| 1. **Minting Tokens** | ||
| - Expected: Successful minting for eligible users. | ||
| - Failures: | ||
| - User already owns a token. | ||
| - Payment amount does not match _price. | ||
|
|
||
| 2. **Voting** | ||
| - Expected: Correct vote recording and prevention of duplicate voting. | ||
| - Failures: | ||
| - Non-token holder participation. | ||
| - Duplicate votes on the same proposal. | ||
|
|
||
| 3. **Ending Voting** | ||
| - Expected: Accurate point adjustment based on majority votes. | ||
| - Failures: | ||
| - Ending before expiration. | ||
| - Inactive proposals. | ||
|
|
||
| 4. **Burning Tokens** | ||
| - Expected: Permanent token removal. | ||
| - Failures: | ||
| - Unauthorized burn attempts. |
Contributor
There was a problem hiding this comment.
Test cases should be either simple inputs and outputs (i.e. function calls and state changes) or actual coded unit tests.
| - **Mitigation of whale attacks**: Restricts tokens to one per wallet. | ||
| - **Non-refundable burning**: Discourages exploitative behaviors. | ||
|
|
||
| Needs discussion. |
Contributor
There was a problem hiding this comment.
Suggested change
| Needs discussion. | |
| <!-- Needs discussion. --> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.