[X Standard] Introduce Your Standard

Intro
1

L1F’s primary mission has always been to serve as the central nexus for all metaprotocol discussions and development. To lay the groundwork and find our rhythm, we began exclusively with brc-20 content. Having now established our stride, we believe it’s the opportune moment to branch out to other protocols. A prevailing challenge in the current landscape is the scattered distribution of documentation across multiple platforms, making it tough to grasp the full spectrum of available information. To address this and usher in a broader range of protocols, we’re reaching out to protocol developers, maintainers, and enthusiasts to introduce their standards to the forum. We hope this will streamline the information flow within the ecosystem, eliminate redundancy, and bolster collaboration. To standardize this effort we recommend using the format below. A brc-20 version of this will be available for reference here: [brc-20] Introduction to brc-20.

What is [X Standard]? – A Comprehensive Overview

Introduction:

  • Brief description of [X Standard].
  • Historical context or background, if relevant.

Key Features:

  1. Primary Function: Describe the main purpose of the standard.
  2. Technical Specifications: Provide details on its technical aspects.
  3. Interoperability: Discuss how it interacts or integrates with other protocols or systems.
  4. Security Measures: Highlight any built-in security features or practices.

Characteristics:

  • Describe the inherent traits or features of [X Standard].
  • Discuss any unique attributes or differentiators.

Use Cases:

  • Illustrate real-world applications or scenarios where [X Standard] is employed.
  • Mention any notable projects or platforms utilizing [X Standard].

How it Compares to Other Standards:

  • Offer a brief comparison with similar standards in the domain.
  • Point out what sets [X Standard] apart.

Future Developments and Roadmap (if available):

  • Share any forthcoming updates or enhancements.
  • Elucidate on the prospective trajectory of [X Standard] in the wider ecosystem.

Resources and Further Reading:

  • Link to the official documentation or whitepaper.
  • Recommend any articles, videos, or tutorials for deeper exploration.

Discussion:

  • Urge your users to contribute their experiences, insights, or queries about [X Standard].

To prevent spam, topic authorship remains restricted. If you would like to introduce your standard to the forum, please leave a comment below or reach out to me directly @domodata on Twitter.

8 Likes
2

Thanks @domo , you have done the perfect movement. I am the creator of BRC-100 protocol stack, and I have some protocols or proposals to discuss here. Please give me the authorship to post topic.
My twitter is: @MikaelBTC
Thanks again for doing this.

2 Likes
3

thank @domo for sharing, im

1 Like
4

Fairlight Collateralized Debt Position (CDP) Protocol

Abstract

The Fairlight protocol introduces a sophisticated JavaScript-based Collateralized Debt Position (CDP) system, enabling users to secure cryptocurrency as collateral and engage in advanced financial operations within the blockchain. This documentation provides a comprehensive overview of Fairlight’s functionalities, its integration with a Decentralized Exchange (DEX), and the JSON-based inscription system for streamlined CDP management.

Motivation

Fairlight’s CDP system aims to empower traders in the crypto space, offering enhanced leverage, risk management, and liquidity opportunities. By bridging the gap between traditional finance and decentralized systems, Fairlight facilitates the creation of a robust DeFi ecosystem, emphasizing user autonomy, risk mitigation, and efficient CDP lifecycle management.

Description

Fairlight’s CDP protocol revolves around the core CDP class, which governs the lifecycle of individual CDPs. This class includes methods such as opening and closing CDPs, managing collateral, debt, and interest, as well as handling liquidation scenarios. Additionally, Fairlight leverages a JSON-based inscription system to facilitate seamless interaction with the protocol, enhancing user accessibility and operational clarity.

Core Components

Fairlight’s CDP protocol comprises the following core components:

  • CDP Class: The core CDP class governs the lifecycle of individual CDPs. It includes methods for opening and closing CDPs, managing collateral, debt, and interest, as well as handling liquidation scenarios.

  • Collateral: Users can secure cryptocurrency assets as collateral within the CDP system.

  • Debt: Borrowed cryptocurrency assets are represented as debt within the CDP.

  • Interest: Interest is calculated and managed within the CDP system.

  • JSON-Based Inscription System: Fairlight employs a JSON-based inscription system for users to interact with the protocol seamlessly. This system enhances user accessibility and operational clarity.

Command Operations

Users can interact with the Fairlight CDP protocol through the following command operations:

Open a CDP

{
  "p": "brc20-cdp",
  "op": "open",
  "params": {
    "user": "bc1quseraddress",
    "collateral": 1000,
    "debt": 500
  }
}

Draw Debt

{
  "p": "brc20-cdp",
  "op": "draw",
  "params": {
    "user": "bc1quseraddress",
    "amount": 100
  }
}

Repay Debt

{
  "p": "brc20-cdp",
  "op": "wipe",
  "params": {
    "user": "bc1quseraddress",
    "amount": 100
  }
}

Close a CDP

{
  "p": "brc20-cdp",
  "op": "close",
  "params": {
    "user": "bc1quseraddress"
  }
}

Check for Liquidation

{
  "p": "brc20-cdp",
  "op": "checkLiquidation",
  "params": {
    "user": "bc1quseraddress"
  }
}

These command operations provide users with a structured approach to managing their CDPs within the Fairlight protocol, promoting transparency and efficiency in blockchain financial operations.

FAQ

  1. What is the minimum collateral required to open a CDP?
    The minimum collateral required is 1.

  2. How often is interest accrued on CDP debt?
    Interest accrues daily.

  3. What happens during liquidation of a CDP?
    If a CDP’s collateral-to-debt ratio falls below a certain threshold (e.g., 150%), it becomes eligible for liquidation. The collateral is sold to repay the debt, potentially on a Decentralized Exchange (DEX) if integrated.

Acknowledgments

We would like to acknowledge the developers, contributors, and the open-source community for their continuous support and commitment to the Fairlight protocol.

Source

This documentation provides a comprehensive guide to the Fairlight Collateralized Debt Position (CDP) protocol, enabling users to harness the power of cryptocurrency collateral for advanced financial operations within the blockchain ecosystem.

3 Likes
5

Thank you. It’s a good example.

2 Likes
6

[BRC-223] Introduction to BRC-223

BRC-223 is a more advanced version of BRC-20, which simplifies the interaction between smart contracts and tokens. BRC-223 aims to address the limitations of BRC-20.

The BRC-223 standard is backwards compatible with BRC-20, meaning you can interact with these tokens as if they were BRC-20, using the standard functions. Any platform working with BRC-20 will also work with BRC-223.

An important aspect of deploying, minting, and sending tokens is the data and operatorData parameters, which is an enhancement over BRC-20 where only the recipient and amounts of tokens can be specified as part of a transfer. This allows new and exciting use cases such as accepting transfers only if a signed message is provided or specify a purpose for a transfer such that a recipient contract can take appropriate actions.

The data parameter is intended to be similar to the data parameter of a regular Ethereum transaction, and the standard intentionally does not enforce a specific format for this data only that the recipient defines what data it expects.

The operatorData is the second free bytes parameter associated with a token transaction. It is similar to the data parameter, except that it is explicitly intended for the operator to provide any information or reason for the transaction. In contrast, the data parameter may be provided by either the token holder, the operator, or both.

Ultimately the recipient is free to define which data and operatorData it expects and reject any transaction which does not match its expectations. In practice, we expect the recipient to mainly focus on the data parameter, with the operatorData only providing optional and additional information regarding the transfer.

One key aspect for the BRC-223 standard is to maintain backward compatibility with the older BRC-20 standard. The BRC-223 standard also allows some forward-compatibility. Namely, the format of the data and operatorData have been left free for future standard to define specific formats they need.

7

BRC-223 is a more advanced version of BRC-20, which simplifies the interaction between smart contracts and tokens. BRC-223 aims to address the limitations of BRC-20.

Learn more here:
docs.bitcoints(dot)org

8

@domo The BRC-20 standard is brilliant, but it has some limitations

9

@domo
The most popular fungible token standards on ethereum are ERC-20 and ERC-223.

We believe that the most popular fungible token standards on bitcoin will be BRC-20 and BRC-223.

1 Like
10

BRC-223 was modeled after the ERC-223 standard.

Just like BRC-20 was modeled after the ERC-20 standard.

2 Likes
12

Hi @domo

Alex Taggart recommended that I submit an introduction of the BRC333 protocol.

I spent some time on an introduction of the BRC333 protocol but when I tried to post, I got this:
“An error occurred: You are not permitted to view the requested resource.”

1 Like