> For the complete documentation index, see [llms.txt](https://8bit-1.gitbook.io/drc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://8bit-1.gitbook.io/drc/recursive-doginals.md).

# Recursive Doginals

Recursive standard for the Dogecoin blockchain and DRC-20 Protocol

Designing a new protocol for a cryptocurrency like Dogecoin is a complex task that requires careful consideration of various technical, security, and practical aspects. Below is a high-level outline of a possible protocol that incorporates ordinals called "doginals" and recursive inscriptions called "shibescriptions" for referencing endpoint APIs immutably. Please note that this is a conceptual outline and not a fully detailed implementation.

1. 1.**Doginals:**
   * Doginals are unique ordinal identifiers assigned to specific data or events on the Dogecoin blockchain. They act as immutable references to these data points.
   * To generate a doginal, a user would calculate a cryptographic hash (e.g., SHA-256) of the data or event they wish to reference.
   * The first 'n' characters of the resulting hash (where 'n' is configurable) would be used as the doginal identifier.
2. 2.**Shibescriptions:**
   * Shibescriptions are recursive inscriptions or metadata entries that point to endpoint APIs.
   * Each shibescription consists of the following:
     * Doginal: The doginal of the referenced data or event.
     * API Endpoint: The URL of the endpoint API being referenced.
     * Additional Metadata: Any other relevant information or metadata about the API.
3. 3.**Smart Contracts:**
   * To enable the creation and validation of shibescriptions, smart contracts could be utilized.
   * Users can submit shibescriptions to specific smart contract functions along with the required fee (in Dogecoin) to cover transaction costs and storage on the blockchain.
   * The smart contract would validate the doginal's existence and verify that the provided API endpoint is accessible and secure.
4. 4.**API Endpoint Verification:**
   * As part of the validation process, the smart contract could execute a test call to the API endpoint provided in the shibescription to ensure it returns the expected response.
   * This step would help prevent malicious actors from submitting invalid or potentially harmful API references.
5. 5.**Data Immutability:**
   * Once a shibescription is validated and added to the blockchain, it becomes immutable, meaning the reference to the API endpoint cannot be altered or deleted.
   * If an API endpoint needs to be updated or replaced, a new shibescription with the updated information can be submitted, and users can choose to reference the updated endpoint if they wish.
6. 6.**Querying APIs:**
   * Users and applications can use the doginals referenced in shibescriptions to query specific data points or events directly from the blockchain.
   * This feature provides an immutable and transparent way to access and verify data from external sources.
7. 7.**Security Considerations:**
   * The smart contract implementation must be thoroughly audited for security vulnerabilities to prevent exploits or attacks.
   * Users should exercise caution when referencing APIs to avoid potential risks associated with external data sources.

Please note that this protocol outline is a starting point, and additional considerations and optimizations may be needed during the actual implementation process. Developing a functional and secure protocol requires a team of experienced blockchain developers, auditors, and security experts to ensure it meets the required standards for deployment on the Dogecoin network.