BitBadges
  • Overview
    • ๐Ÿ‘‹BitBadges Overview
    • ๐Ÿ‘จโ€๐Ÿ’ปLearn the Basics
      • BitBadges Claims
      • Multi-Chain Accounts
      • Sign In with BitBadges
      • Badges
      • Address Lists
      • Attestations
      • Applications (Points)
      • Additional Badge Concepts
        • Manager
        • Total Supplys
        • Time-Dependent Ownership
        • Transferability
        • Balances Types
      • Wallets and Sign Ins
        • Supported Wallets
        • Alternate Sign Ins / Mobile
        • Approved Transactors
    • ๐Ÿ”จGetting Started
    • ๐Ÿ’ปHow Do I Check...?
    • ๐Ÿ”How Do I Gate...?
    • ๐ŸŽจUse Cases
    • ๐Ÿ”—Official Links and Resources
    • โš–๏ธBitBadges L1 vs Others
    • ๐Ÿช™Launch Phases
    • ๐ŸŒดEcosystem
      • WordPress Plugin
      • MetaMask Snap
      • Browser Extensions
      • LinkedIn Certifications
      • Blockin
    • ๐ŸคBrand Guidelines
    • โ“FAQ
  • โŒจ๏ธFor Developers
    • ๐Ÿšดโ€โ™‚๏ธGetting Started
    • ๐Ÿ‘คHandling Addresses
    • ๐ŸงชTestnet Mode
    • ๐Ÿ“šBitBadges API
      • Getting Started
      • Full Reference
      • Typed SDK Types
      • Upgrading an API Key Tier
      • Concepts
        • Native Chain Algorithm
        • Refresh / Claim Completion Queue
        • Designing for Compatibility
        • Limits / Restrictions
        • Managing Views
        • Use via Pipedream
    • ๐Ÿ–ฑ๏ธSign In with BitBadges
      • Overview
      • Already Have Web3 Auth?
      • Alternative - P2P Verification
      • Templates and Frameworks
        • WordPress
        • Auth0
        • ExpressJS
        • Discourse
        • Supabase
        • Others
      • Setting Up an App
      • Connecting a Claim
      • Authorization URL
        • Configuration
        • Generating the URL
      • Approaches
        • QR Codes
        • Redirect Callback
      • Verification
        • Verification Flow
        • Access Tokens
        • Offline Verification
        • Security Considerations
      • Blockin Docs
    • ๐Ÿ—๏ธBitBadges Claims
      • Overview
      • Concepts
        • Standard vs On-Demand
        • Completion Methods
        • Gating Badge Distribution
        • Claim Numbers
        • Success Logic
        • Claim Links (URLs)
        • Signed In vs Select Address
        • Universal Approach - Claim Codes
        • Identify By Socials / Emails?
        • Payment Checking
        • Receiving Attestations
      • Checking Custom Criteria
      • Implementing Custom Utility
      • Leveraging AI
      • BitBadges API & Claims
        • Verifying Claim Attempts w/ the API
        • Fetching Claims
        • Auto-Complete Claims w/ BitBadges API
      • Dynamic Stores
        • Overview
        • Adding Data
      • Custom Plugins / Webhooks
        • Overview
        • Pre-Built Webhook Plugins
        • Creating a Custom Plugin
          • Implement Your Plugin
            • Getting Started
            • Hook Types and Simulations
            • Design Considerations
            • Parameters
            • Custom Inputs
            • API Handler
          • Managing Your Plugin
          • Testing Your Plugin
        • Configuration Tools
      • Integrate with Zapier
        • Overview
        • Dynamic Store Zaps
        • Automatic Claim Tutorial
        • Post-Success Zaps
        • Leveraging Zapier AI Actions / MCP
        • Automate Any Part of the Process
          • Google Forms
      • Integrate with Pipedream
        • Overview
        • Leveraging Pipedream MCP
        • Build Custom Plugins
        • Workflow Actions
          • Complete Claim
          • Get Claim Attempt Status
          • Get Claim Code by Idx
          • Add User to Dynamic Store
        • Workflow Triggers
          • Poll Claim Attempts
        • End to End Example
      • In-Site Plugins
        • Plugins Directory
        • Plugin Documentation
        • Ownership Requirements
      • Tutorials
        • In-Site Guides
        • Get Integration User IDs
          • Get Discord User ID
          • Get Discord Server ID
          • X / Twitch / GitHub IDs
        • Add Telegram Bot to Channel
    • โš’๏ธBitBadges JS / SDK
      • Overview
      • SDK Types
      • Common Snippets
        • Address Conversions
        • NumberType Conversions
        • Uint Ranges
        • Balances
        • Transfers
        • Address Lists
        • Badge Metadata
        • Approvals / Transferability
        • Off-Chain Balances
        • Timelines
    • ๐ŸŒŸBadges - Advanced
      • Overview
      • Balances / Transfers
        • ๐Ÿ“ŠBalances
        • โž•Valid Badge IDs
        • ๐Ÿช™Balance Types
        • ๐ŸคTransferability / Approvals
        • โœ…Approval Criteria
          • Overview
          • $BADGE Transfers
          • Override User Level Approvals
          • Approval Trackers
          • Tallied Approval Amounts
          • Max Number of Transfers
          • Predetermined Balances
          • Requires
          • Merkle Challenges
          • Extending the Approval (Advanced)
      • Self-Hosted Balances
        • Overview
        • Examples / Tutorials
          • Indexed
          • Non-Indexed
      • Permissions
        • Overview
        • Action Permission
        • Timed Update Permission
        • Timed Update With Badge Ids Permission
        • Badge IDs Action Permission
        • Update Approval Permission
      • Standards
      • Archived Collections
      • Metadata
      • Timelines
      • Different Time Fields
      • List IDs
      • Uint Ranges
    • โ›“๏ธBitBadges Blockchain
      • Overview
      • Chain Details
      • REST API Docs - Node
      • Staking / Validators
      • Run a Node
        • Overview
        • Run a Mainnet Node
        • Run a Local Dev Node
        • Cosmovisor
      • Create a Smart Contract
      • ๐Ÿ”ƒCreate, Generate, and Sign Txs
        • Transaction Context
        • Generate Msg Contents
        • Signing - Cosmos
        • Signing - Ethereum
        • Signing - Solana
        • Signing - Bitcoin
        • Broadcast to a Node
        • Sign + Broadcast - bitbadges.io
      • ๐Ÿ“ฉCosmos SDK Msgs
        • x/anchor
          • MsgAddCustomData
        • x/badges
          • MsgCreateCollection
          • MsgUpdateCollection
          • MsgDeleteCollection
          • MsgCreateAddressLists
          • MsgTransferBadges
          • MsgUpdateUserApprovals
          • MsgUniversalUpdateCollection
        • x/wasmx
          • MsgStoreCodeCompat
          • MsgInstantiateContractCompat
          • MsgExecuteContractCompat
        • x/maps
          • MsgCreateMap
          • MsgUpdateMap
          • MsgDeleteMap
          • MsgSetValue
        • MsgSend
        • Cosmos Native Msgs
    • ๐Ÿง Other Concepts
      • Uint Ranges
      • Accounts (Low-Level)
      • Address Lists
      • Maps / Protocols
      • Attestations - Advanced
        • Overview
        • Creating an Attestation
        • Custom Creation Links
        • Proofs vs Attestations
        • Deriving a Proof
        • Design Considerations
        • Verification / Presentations
        • Custom Schemes
          • WITNESS Proofs
Powered by GitBook
On this page
  1. For Developers
  2. Other Concepts

Maps / Protocols

Maps are similar to anchors, but they allow you to store data on-chain in a structured way. They are simply key-value maps, and the configuration can be set with customization options like "no duplicates", "expect integere values"", and so on. With maps, you can create universal, reusable, flexible protocols for your users.

{
    "bb...1234": "English",
    "bb...5678": "Spanish"
}
{
    "BitBadges Follow Protocol": 12, //collection ID 12 is used for my follows
    "Experiences Protocol": 13
}

This is all facilitated through the x/maps module and its correspondingMsgs. See the Msgs for more information.

export interface iMap<T extends NumberType> {
    creator: string;
    mapId: string;
    inheritManagerTimelineFrom: T;
    managerTimeline: iManagerTimeline<T>[];
    updateCriteria: iMapUpdateCriteria<T>;
    valueOptions: iValueOptions;
    defaultValue: string;
    permissions: iMapPermissions<T>;
    metadataTimeline: iMapMetadataTimeline<T>[];
}

Reserved Maps

All maps are identified by a mapId. The following mapId values are reserved:

  • Any valid Bech32 BitBadges address - These are reserved for maps that can only be created by that specific address. This can be a place to store important values custom to you (that address).

  • Any numeric ID is reserved for the corresponding badge collection with a matching ID. This can only be created by the badge collection manager. This can be used to store core details that belong on-chain for the collection not handled by the core badge collection interface.

Use Cases

  • Alternative permissions - Store other permissions related to a collection in these maps on-chain

  • Router for important information - For example, lets say thte collection has credentials attached to it. This can point to where the credentials can be found or important info needed to verify them.

  • Protocols - On the next page, we expand on the concept of protocols which allow users to specify what collection they want to use for a certain protocol (e.g. use my collection 10 for the Follow Protocol).

Manager

The manager is similar to the badges interface. They are granted admin privileges to update certain things about the map.This is handled by managerTImeline and the canUpdateManager permission.

Maps also have the option to inheritManagerTimelineFrom a specific collection. This emans that the manager of the badge collection specified will be used instead of the managerTimeline field.

Genesis Conditions

Protocols may have expected genesis conditions or additional checks to be correctly implemented. There are no checks on-chain for genesis conditions but these can be handled by you.

Map Type

There are really four different map types.

  • Manager only means only the manager can update values

  • Collection ID means map key smust be numeric and only owners of badge ID N from the collection ID specified can update key = N.

  • Creator only means keys are address-based. You can only update the value for your address. This uses mapped BitBadges addresses.

  • First come, first serve means that map slots are open but once claimed, they can not be overwritten unless unset by the user who claimed the slot.

export interface iMapUpdateCriteria<T extends NumberType> {
    managerOnly: boolean;
    collectionId: T;
    creatorOnly: boolean;
    firstComeFirstServe: boolean;
}

Permissions / Expected Values

export interface iValueOptions {
    noDuplicates: boolean;
    permanentOnceSet: boolean;
    expectUint: boolean;
    expectBoolean: boolean;
    expectAddress: boolean;
    expectUri: boolean;
}
export interface iMapPermissions<T extends NumberType> {
    canUpdateMetadata: iTimedUpdatePermission<T>[];
    canUpdateManager: iTimedUpdatePermission<T>[];
    canDeleteMap: iActionPermission<T>[];
}

Map Metadata

Map metadata follows the same interfaces as badges and address lists.

export interface iMapMetadataTimeline<T extends NumberType> {
    timelineTimes: iUintRange<T>[];
    metadata: iCollectionMetadata;
}
PreviousAddress ListsNextAttestations - Advanced

Last updated 6 months ago

โŒจ๏ธ
๐Ÿง