diff --git a/.env.example b/.env.example index e4d41e4..b9edf8a 100644 --- a/.env.example +++ b/.env.example @@ -5,4 +5,5 @@ GNOSIS_URL=https://rpc.gnosischain.com/ ETHERSCAN_API_KEY= ALCHEMY_ENDPOINT_URL=https://eth-goerli.alchemyapi.io/v2/ TENDERLY_PROJECT="" -TENDERLY_USERNAME="" \ No newline at end of file +TENDERLY_USERNAME="" +REPORT_GAS=true \ No newline at end of file diff --git a/ERC1155 Architecture.md b/ERC1155 Architecture.md new file mode 100644 index 0000000..8ce3d12 --- /dev/null +++ b/ERC1155 Architecture.md @@ -0,0 +1,54 @@ +

+ + TheBadge + +

+ +

TheBadge DApp Smart-contracts

+ +

+ Join to Discord + Follow us on Twitter +

+ +For questions or request information reach out via [Discord](https://discord.gg/tVP75NqVuC). + +# TheBadge: a non-dynamic data oracle for web3 certifications. + +## Introduction + +TheBadge is a novel decentralized platform that leverages the ERC1155 token standard to represent unique badges. These badges, referred to as SBT (Special Badges Tokens), hold distinct on-chain information for each user. Unlike traditional tokens, SBTs cannot be transferred or traded, as they embody exclusive user-specific data. + +TheBadge's architecture is divided into two key components: "Badge Models" and "Badges." Badge Models are defined by badge creators and serve as templates for generating actual badges that end-users will possess. A Badge Model specifies not only the visual design of the badge but also governs how the information within it should be displayed and validated. + +## Architecture Description + +![SC-Architecture](assets/images/SC-Architecture.png) + +### Badge Models + +Badge Models play a pivotal role in TheBadge ecosystem. These models are created by the badge creators and set the standards for generating individual badges. Each Badge Model defines: + +1. **Visual Design**: The appearance and layout of the badge. +2. **Information Presentation**: How the data contained within the badge should be displayed. +3. **Validation Process**: The criteria and methods for validating the information. + +Presently, there are two distinct types of Badge Models within TheBadge: + +#### 1. KlerosBadgeModel + +These badges, also known as "Community badges," are issued based on a curated list maintained by Kleros. The KlerosBadgeModel can be challenged and potentially rejected by jurors participating in Kleros courts, following a challenge initiated by a TheBadge curator. + +#### 2. ThirdPartyBadgeModel + +These badges, also known as "Third-Party badges," are exclusively issued by previously registered and validated third-party companies that are part of TheBadge ecosystem. Each ThirdPartyBadgeModel operates as a TCR (Token-Curated Registry) list within the Kleros court. Importantly, these lists are non-challengeable, and only the third-party company administrators have the authority to add or remove badges from the list, including the power to revoke credentials granted to their users. + +### Badge Controllers + +The core of TheBadge's smart contract architecture lies in the ability to incorporate additional "Badge controllers" in the future, catering to diverse use cases. This flexibility allows for the expansion of TheBadge's capabilities, including support for various badge-related functionalities, such as zkBadges and third-party curation. + +The central concept is that TheBadge comprises a significant ERC1155 contract, which is dependent on controllers. Each controller is responsible for managing the logic associated with specific badge models. By introducing more controllers, TheBadge's versatility increases, providing endless possibilities for badge-related applications. + +## Conclusion + +TheBadge introduces an innovative decentralized badge ecosystem based on the ERC1155 token standard. This ecosystem is designed to support various badge models and controllers, offering a dynamic and versatile platform for unique on-chain badge representation. With Badge Models catering to diverse use cases and the potential for expanding the ecosystem with new Badge controllers, TheBadge presents a promising frontier in the world of decentralized digital credentials. diff --git a/ERC1155-721 Architecture.md b/ERC1155-721 Architecture.md deleted file mode 100644 index 653f01d..0000000 --- a/ERC1155-721 Architecture.md +++ /dev/null @@ -1,46 +0,0 @@ -

- - TheBadge - -

- -

TheBadge DApp Smart-contracts

- -

- Join to Discord - Follow us on Twitter -

- -For questions or request information reach out via [Discord](https://discord.gg/tVP75NqVuC). - -# TheBadge ERC1155-721 Badges architecture - -## Introduction: - -The Ethereum blockchain has two existing token standards for creating non-fungible tokens (NFTs) – ERC1155 and ERC721. While ERC721 is an older and more established standard, it can only create unique and indivisible tokens. In contrast, ERC1155 tokens can be both unique and interchangeable, making them suitable for creating multiple instances of the same asset with different properties. However, neither of these standards alone can cater to the use case of TheBadge, which requires a mix of both standards. - -### Why is it not possible to follow only one standard? - -TheBadge needs to track two types of information: BadgeModels and Badges. BadgeModels are templates that represent a validation strategy, such as owning a Twitter or YouTube handle. Badges are issued to users who provide evidence of following the criteria set by the BadgeModels. ERC1155 tokens can track BadgeModels, but they cannot distinguish among different badges for example with different due dates or a specific badge image for each asset, which cannot be achieved through ERC1155 alone. - -### Our Solution: Mixing Standards - -We propose a solution that combines the benefits of both ERC721 and ERC1155 standards. The BadgeModels will be represented with the token ID (unique auto-incremental) and well each Badge will have its own unique auto-incremental ID. Although the minting process will be treated as ERC1155, the events triggered will be sent as if we were using an ERC721 standard, where each asset is unique. This modification will require us to make some conceptual changes to the ERC1155 standard. - -### Conceptual Changes: - -One ID per token: We will track each BadgeModels with its own auto-incremental ID. -One ID per badge: We will track each Badge with its own auto-incremental ID. -Event TransferSingle: We will use the badge ID instead of the BadgeModeld. Note that the mint method will receive BadgeModeld. -Event URI: We will use the badge ID instead of the BadgeModeld. - -### Standard aggregation: Badge external ID On-Chain Verification - -To distinguish between different badges of the same BadgeModel, TheBadge will issue each Badge with a unique Badge ID. We will use IPFS to store the Badge metadata off-chain, but it is not possible to link a Badge ID with a specific user handle on IPFS at a smart-contract level. To solve this problem, we will add a new public mapping that links each BadgeModel ID with a Badge External ID and an address. This mapping will track if a particular address has control over a specific user handle, as shown below: - -“map(Twitter => @goku => 0x345)”; -“map(Twitter => @vegeta => 0x345)” - -### Here is a diagram of our architecture: - -![Drag Racing](./assets/images/ERC1155-721 Architecture.png) diff --git a/README.md b/README.md index aa67ba0..16363aa 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@

- TheBadge + TheBadge

@@ -23,27 +23,6 @@ For questions or request information reach out via [Discord](https://discord.gg/ yarn ``` -### Testing - -To run the tests: - -```bash -yarn build -yarn test -``` - -Optionally, if you want to run the ERC-4337 compatibility test, it uses a live bundler and node, so it contains some pre-requisites: - -1. Define the environment variables: - -``` -ERC4337_TEST_BUNDLER_URL= -ERC4337_TEST_NODE_URL= -ERC4337_TEST_SINGLETON_ADDRESS= -ERC4337_TEST_SAFE_FACTORY_ADDRESS= -MNEMONIC= -``` - 2. Pre-fund the executor account derived from the mnemonic with some Native Token to cover the deployment of an ERC4337 module and the pre-fund of the Safe for the test operation. ### Deployments @@ -59,8 +38,13 @@ A collection of the different contract deployments and their addresses can be fo ``` WALLET_PRIVATE_KEY= GOERLI_URL=https://goerli.infura.io/v3/ +SEPOLIA_URL=https://sepolia.infura.io/v3/ GNOSIS_URL=https://rpc.gnosischain.com/ ETHERSCAN_API_KEY= +ALCHEMY_ENDPOINT_URL=https://eth-goerli.alchemyapi.io/v2/ +TENDERLY_PROJECT="" +TENDERLY_USERNAME="" +REPORT_GAS=true ``` #### Install Rust & Cargo @@ -91,18 +75,28 @@ For troubleshooting check the [fountry installation](https://book.getfoundry.sh/ yarn deploy:goerli ``` +### Upgrade + +``` +yarn upgrade:goerli +``` + ### Verify contract -This command will use the deployment artifacts to compile the contracts and compare them to the onchain code +This command will use the deployment artifacts to compile the contracts and compare them to the onchain code. +It will also verify the contracts on tenderly. -```bash -yarn hardhat --network local-verify +``` +yarn verify:goerli ``` -This command will upload the contract source to Etherescan +### Testing + +To run the tests: ```bash -yarn hardhat --network etherscan-verify +yarn build +yarn test ``` ## Deployments @@ -115,10 +109,6 @@ yarn hardhat --network etherscan-verify - If you want to learn more give a look to our [docs](https://docs.thebadge.xyz/) -## Architecture - - decorative-image-3 - ## Security and Liability All contracts are WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. diff --git a/assets/images/ERC1155-721 Architecture.png b/assets/images/ERC1155-721 Architecture.png deleted file mode 100644 index 1e9899a..0000000 Binary files a/assets/images/ERC1155-721 Architecture.png and /dev/null differ