6 |
30 | );
31 | }
32 |
--------------------------------------------------------------------------------
/app/layout.tsx:
--------------------------------------------------------------------------------
1 | import { RootProvider } from 'fumadocs-ui/provider/next';
2 | import './global.css';
3 | import { JetBrains_Mono } from 'next/font/google';
4 | import type { Metadata } from "next";
5 |
6 | const jetBrainsMono = JetBrains_Mono({
7 | subsets: ['latin'],
8 | });
9 |
10 | export const metadata: Metadata = {
11 | title: "Bifrost Developers",
12 | description: "Comprehensive documentation for developers building with Bifrost protocol",
13 | metadataBase: new URL("https://developers.bifrost.io"),
14 | openGraph: {
15 | title: "Bifrost Developers",
16 | description: "Comprehensive documentation for developers building with Bifrost protocol",
17 | url: "https://developers.bifrost.io",
18 | siteName: "Bifrost Developers",
19 | images: [
20 | {
21 | url: "/bifrost-developers.png",
22 | width: 1200,
23 | height: 630,
24 | alt: "og-image",
25 | },
26 | ],
27 | locale: "en_US",
28 | type: "website",
29 | },
30 | twitter: {
31 | card: "summary_large_image",
32 | title: "Bifrost Developers",
33 | description: "Comprehensive documentation for developers building with Bifrost protocol",
34 | creator: "@bifrost",
35 | images: ["/bifrost-developers.png"],
36 | },
37 | };
38 |
39 | export default function Layout({ children }: LayoutProps<'/'>) {
40 | return (
41 |
42 |
43 |
7 |
29 | 8 | The crosschain staking layer 9 |
10 |11 | Bifrost Developer Documentation 12 |
13 |
14 |
18 | Getting started
19 |
20 |
25 | Videos
26 |
27 |
28 |
7 |
11 |
12 | Bifrost is a **staking yield layer** that establishes a standardized multi-chain liquid staking rewards infrastructure, delivering composable crypto-native yields for stablecoins, RWAs, and DeFi across various blockchains. Its modular design allows developers to tap into multi-chain staking rewards with one integration, greatly lowering development costs and enhancing user simplicity.
13 |
14 | ## Understanding Bifrost
15 |
16 | 
17 |
18 | The easiest way to understand Bifrost is to see it as a derivative issuer that provides liquidity for all pledged assets, issuing corresponding shadow assets during the bonding period of the original assets. At the same time, the shadow asset is a fungible Token that can be circulated in different DEXs, pools, protocols and across chains.
19 |
20 | As a DeFi protocol, Bifrost is aiming to solve the following issues in PoS ecosystems:
21 | - The paradox between staking rewards and DeFi yields
22 | - The balance between staking/circulating tokens and security of PoS chains
23 | - Staking rewards in cross-chain scenario
24 |
25 | According to the questions above, Bifrost's solution vToken (liquid staking voucher Token) enables users to convert their PoS tokens into vTokens in order to obtain staking liquidity and staking rewards synchronously, without barriers in cross-chain scenarios.
26 |
27 | 
28 |
29 | ## Why choose Bifrost?
30 |
31 |
8 |
9 |
10 | 
on the top left corner of this document to get to a specific section of this guide quickly.
10 |
11 | ## New contributor guide
12 |
13 | To get an overview of the project, read the [README](../README.md) file. Here are some resources to help you get started with open source contributions:
14 |
15 | - [Finding ways to contribute to open source on GitHub](https://docs.github.com/en/get-started/exploring-projects-on-github/finding-ways-to-contribute-to-open-source-on-github)
16 | - [Set up Git](https://docs.github.com/en/get-started/getting-started-with-git/set-up-git)
17 | - [GitHub flow](https://docs.github.com/en/get-started/using-github/github-flow)
18 | - [Collaborating with pull requests](https://docs.github.com/en/github/collaborating-with-pull-requests)
19 |
20 | ## Getting started
21 |
22 | To navigate our codebase with confidence, see [Getting Started section](./README.md/#getting-started) :confetti_ball:. For more information on how we write our markdown files, see "[Using Markdown and Liquid in GitHub Docs](https://docs.github.com/en/contributing/writing-for-github-docs/using-markdown-and-liquid-in-github-docs)."
23 |
24 | Check to see what [types of contributions](./CONTRIBUTING.md/#types-of-contributions) we accept before making changes. Some of them don't even require writing a single line of code :sparkles:.
25 |
26 | ### Issues
27 |
28 | #### Create a new issue
29 |
30 | If you spot a problem with the repository or want to suggest some changes, you can open an `issue` in the [Issue tab](https://github.com/bifrost-io/mono/issues)
31 |
32 |
33 | ### Make Changes
34 |
35 | #### Make changes locally
36 |
37 | 1. Fork the repository.
38 | - Using GitHub Desktop:
39 | - [Getting started with GitHub Desktop](https://docs.github.com/en/desktop/installing-and-configuring-github-desktop/getting-started-with-github-desktop) will guide you through setting up Desktop.
40 | - Once Desktop is set up, you can use it to [fork the repo](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/cloning-and-forking-repositories-from-github-desktop)!
41 |
42 | - Using the command line:
43 | - [Fork the repo](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo#fork-an-example-repository) so that you can make your changes without affecting the original project until you're ready to merge them.
44 |
45 | 2. Create a working branch (preferably a branch with your GitHub username) and start with your changes!
46 |
47 | ### Commit your update
48 |
49 | Commit the changes once you are happy with them :zap:.
50 |
51 | ### Pull Request
52 |
53 | When you're finished with the changes, create a pull request, also known as a PR.
54 | - Fill the "Ready for review" template so that we can review your PR. This template helps reviewers understand your changes as well as the purpose of your pull request.
55 | - Don't forget to [link PR to issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if you are solving one.
56 | - Enable the checkbox to [allow maintainer edits](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork) so the branch can be updated for a merge.
57 | Once you submit your PR, a Docs team member will review your proposal. We may ask questions or request additional information.
58 | - We may ask for changes to be made before a PR can be merged, either using [suggested changes](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request) or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
59 | - As you update your PR and apply changes, mark each conversation as [resolved](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request#resolving-conversations).
60 | - If you run into any merge issues, checkout this [git tutorial](https://github.com/skills/resolve-merge-conflicts) to help you resolve merge conflicts and other issues.
61 |
62 | ### Your PR is merged!
63 |
64 | Congratulations :tada::tada: Kaia Foundation thanks you :sparkles:.
65 |
66 | Once your PR is merged, your contributions will be publicly visible on the [https://github.com/bifrost-io/mono](https://github.com/bifrost-io/mono).
67 |
68 | Now that you are part of the Kaia OSS community, see how else you can [contribute to the OSS ecosystem](./CONTRIBUTING.md/#types-of-contributions).
69 |
70 |
71 | ## Types of contributions
--------------------------------------------------------------------------------
/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
1 | # Contributor Covenant Code of Conduct
2 |
3 | ## Our Pledge
4 |
5 | We as members, contributors, and leaders pledge to make participation in our
6 | community a harassment-free experience for everyone, regardless of age, body
7 | size, visible or invisible disability, ethnicity, sex characteristics, gender
8 | identity and expression, level of experience, education, socio-economic status,
9 | nationality, personal appearance, race, religion, or sexual identity
10 | and orientation.
11 |
12 | We pledge to act and interact in ways that contribute to an open, welcoming,
13 | diverse, inclusive, and healthy community.
14 |
15 | ## Our Standards
16 |
17 | Examples of behavior that contributes to a positive environment for our
18 | community include:
19 |
20 | * Demonstrating empathy and kindness toward other people
21 | * Being respectful of differing opinions, viewpoints, and experiences
22 | * Giving and gracefully accepting constructive feedback
23 | * Accepting responsibility and apologizing to those affected by our mistakes,
24 | and learning from the experience
25 | * Focusing on what is best not just for us as individuals, but for the
26 | overall community
27 |
28 | Examples of unacceptable behavior include:
29 |
30 | * The use of sexualized language or imagery, and sexual attention or
31 | advances of any kind
32 | * Trolling, insulting or derogatory comments, and personal or political attacks
33 | * Public or private harassment
34 | * Publishing others' private information, such as a physical or email
35 | address, without their explicit permission
36 | * Other conduct which could reasonably be considered inappropriate in a
37 | professional setting
38 |
39 | ## Enforcement Responsibilities
40 |
41 | Community leaders are responsible for clarifying and enforcing our standards of
42 | acceptable behavior and will take appropriate and fair corrective action in
43 | response to any behavior that they deem inappropriate, threatening, offensive,
44 | or harmful.
45 |
46 | Community leaders have the right and responsibility to remove, edit, or reject
47 | comments, commits, code, wiki edits, issues, and other contributions that are
48 | not aligned to this Code of Conduct, and will communicate reasons for moderation
49 | decisions when appropriate.
50 |
51 | ## Scope
52 |
53 | This Code of Conduct applies within all community spaces, and also applies when
54 | an individual is officially representing the community in public spaces.
55 | Examples of representing our community include using an official e-mail address,
56 | posting via an official social media account, or acting as an appointed
57 | representative at an online or offline event.
58 |
59 | ## Enforcement
60 |
61 | Instances of abusive, harassing, or otherwise unacceptable behavior may be
62 | reported to the community leaders responsible for enforcement at
63 | 0x.stim@klaytn.foundation.
64 | All complaints will be reviewed and investigated promptly and fairly.
65 |
66 | All community leaders are obligated to respect the privacy and security of the
67 | reporter of any incident.
68 |
69 | ## Enforcement Guidelines
70 |
71 | Community leaders will follow these Community Impact Guidelines in determining
72 | the consequences for any action they deem in violation of this Code of Conduct:
73 |
74 | ### 1. Correction
75 |
76 | **Community Impact**: Use of inappropriate language or other behavior deemed
77 | unprofessional or unwelcome in the community.
78 |
79 | **Consequence**: A private, written warning from community leaders, providing
80 | clarity around the nature of the violation and an explanation of why the
81 | behavior was inappropriate. A public apology may be requested.
82 |
83 | ### 2. Warning
84 |
85 | **Community Impact**: A violation through a single incident or series
86 | of actions.
87 |
88 | **Consequence**: A warning with consequences for continued behavior. No
89 | interaction with the people involved, including unsolicited interaction with
90 | those enforcing the Code of Conduct, for a specified period of time. This
91 | includes avoiding interactions in community spaces as well as external channels
92 | like social media. Violating these terms may lead to a temporary or
93 | permanent ban.
94 |
95 | ### 3. Temporary Ban
96 |
97 | **Community Impact**: A serious violation of community standards, including
98 | sustained inappropriate behavior.
99 |
100 | **Consequence**: A temporary ban from any sort of interaction or public
101 | communication with the community for a specified period of time. No public or
102 | private interaction with the people involved, including unsolicited interaction
103 | with those enforcing the Code of Conduct, is allowed during this period.
104 | Violating these terms may lead to a permanent ban.
105 |
106 | ### 4. Permanent Ban
107 |
108 | **Community Impact**: Demonstrating a pattern of violation of community
109 | standards, including sustained inappropriate behavior, harassment of an
110 | individual, or aggression toward or disparagement of classes of individuals.
111 |
112 | **Consequence**: A permanent ban from any sort of public interaction within
113 | the community.
114 |
115 | ## Attribution
116 |
117 | This Code of Conduct is adapted from the [Contributor Covenant][homepage],
118 | version 2.0, available at
119 | https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
120 |
121 | Community Impact Guidelines were inspired by [Mozilla's code of conduct
122 | enforcement ladder](https://github.com/mozilla/diversity).
123 |
124 | [homepage]: https://www.contributor-covenant.org
125 |
126 | For answers to common questions about this code of conduct, see the FAQ at
127 | https://www.contributor-covenant.org/faq. Translations are available at
128 | https://www.contributor-covenant.org/translations.
129 |
--------------------------------------------------------------------------------
/content/docs/hackathons/dot-your-future-oneblock-2025.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Dot Your Future OneBlock Hackathon 2025
3 | description: Bifrost Dot Your Future Hackathon challenge
4 | ---
5 |
6 | ## Context
7 | Bifrost is a Liquid Staking app-chain tailored for all blockchains, utilizing decentralized cross-chain interoperability to empower users to earn staking rewards and DeFi yields with flexibility, liquidity, and high security across multiple chains.
8 |
9 | ## Challenge details
10 | **Design and implement a novel and high-quality user experience for interacting with Bifrost’s widely used liquid staking tokens in a multi-chain environment on Polkadot.**
11 |
12 | We encourage participating teams to prioritize a user-centric perspective, creating smooth and intuitive front-end interaction flows that support functions such as minting, redeeming, and real-time status tracking of liquid staking tokens.
13 |
14 | To achieve this, you can:
15 | - Building a new front-end interaction interface to optimize the overall user journey of Bifrost liquid staking
16 | - Enabling visual monitoring and management of staked assets across multiple chains
17 | - Designing clear and user-friendly data display and operation feedback mechanisms
18 |
19 | ## Judging criteria
20 | - **Originality**: Whether the solution demonstrates innovation and differentiated design
21 | - **User Experience**: Smoothness of interaction, clarity of visuals, and ease of use of functions
22 | - **Technical Implementation**: Code completeness, architectural rationality, and functional stability
23 |
24 | **Note:** AI-assisted development is allowed. However, please note that AI-generated content may have potential issues. Use it cautiously and conduct your own code review.
25 |
26 | ## Requirements
27 | - The project must be fully open-source. All relevant code repository links must be provided upon submission.
28 | - The same project may be submitted multiple times with optimized versions, but each submission must demonstrate key functional improvements.
29 | - The project must be deployed on a Bifrost-compatible testnet or mainnet. In essence, Passet Hub and Moonbase Alpha (Moonbeam Testnet).
30 |
31 | ## Submission guidelines
32 | - Go to the Issue section for this GitHub repo: https://github.com/bifrost-io/mono/issues
33 | - Use the proposal template to create a proposal describing your idea. Include this short sentence at the end of your proposal title "- Dot Your Future: Create, Connect, Transform".
34 | - Upon receiving the `approved` tag for your issue, you can start working on the submission. Should be within 2-3 hours.
35 | - Once you are done with your submission, submit the open source GitHub repo links and deployed links for your submission in the previously created Issue.
36 | - Grant will be evaluated by the Grant Committee
37 | - Initial evaluation & feedback will be communicated with applicants as soon as possible from the date of submission.
38 | - Re-submission and adjustments could be required.
39 | - We will assign a grant amount based on the quality of the submission.
40 | - The grant Committee will vote to approve payment of the proposal.
41 | - The committee can decide to accept the application in whole / partially or reject it.
42 | - The Grant Committee will communicate their decision (approval or rejection) to the applicant. Your issue will be marked `cleared` after payout has been approved and `paid` after payout has been transferred.
43 | - Accepted grant applications will be published on the [Bifrost forum](https://bifrost.subsquare.io/).
44 | - For receiving the grant, you need to provide your Bifrost wallet address. Follow these steps:
45 | - Create a repository in your GitHub account named `bifrost-io`.
46 | - Create a file inside the repository named `funding.json`.
47 | - Add the following JSON to the file:
48 | ```
49 | {
50 | "bifrost": "your_bifrost_wallet_address"
51 | }
52 | ```
53 | - Wait for payout
54 |
55 | ## Resources
56 | - Short video explainer: [Youtube](https://youtu.be/44ZAQX2FwNs?si=pzhHUiQQ-_tUJegF)
57 | - Docs for human: [https://docs.bifrost.io](https://docs.bifrost.io)
58 | - Mono repo: [https://github.com/bifrost-io/mono](https://github.com/bifrost-io/mono)
59 | - Builder program: [https://github.com/bifrost-io/mono/tree/main/builder-program](https://github.com/bifrost-io/mono/tree/main/builder-program)
60 | - AI friendly docs: [https://github.com/bifrost-io/mono/blob/main/docs](https://github.com/bifrost-io/mono/blob/main/docs)
61 | - Bifrost UI kit: [https://github.com/buildstationorg/bifrost-ui-kit](https://github.com/buildstationorg/bifrost-ui-kit)
62 | - Bifrost Dev Kit: [https://github.com/buildstationorg/bifrost-dev-kit](https://github.com/buildstationorg/bifrost-dev-kit)
63 | - Ask any questions by tagging [@FrostyLst](https://x.com/FrostyLst) on X.
64 |
65 | ## Prizes
66 | - Individual awards range from $300 to $1000, with specific amounts determined based on project quality.
67 | - Exceptional projects may receive higher rewards.
68 | - For reference of previously funded projects, see: [Closed Issues](https://github.com/bifrost-io/mono/issues?q=is%3Aissue%20state%3Aclosed)
69 | - Total prize pool status: [Mimir Bifrost Grant Fund](https://app.mimir.global/?address=136qTNfobHieiT4CHYLwNcrjUj92YBYV8BViaj49LCx5AW5z&network=bifrost-polkadot&tab=asset)
70 | ### 🪧 Hackathon Special Awards (Sponsored by Bifrost: 2500 USDT in BNC)
71 | - 🌟 Best Innovation Award: 500U × 1 winner
72 | - ⚙️ Best Technical Implementation Award: 500U × 1 winner
73 | - 🎯 Potential Award: 300U × 5 winners
74 |
75 | ## Post-Hackathon Incubation Support
76 | - Bifrost will provide ongoing support for outstanding projects, including:
77 | - Additional project funding and technical guidance
78 | - Matching with marketing interns to assist promotion
79 | - Revenue sharing program to support sustainable business models
80 |
81 | ## Timeline
82 | ⏰ Sep 11 —— Hackathon registration begins
83 | ⏳ Oct 20 —— Early-bird registration deadline
84 | 📅 Oct 27 —— Code submission deadline `
85 | 💻 Oct 30 —— Demo Day（Online）
--------------------------------------------------------------------------------
/content/docs/protocol-security.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Protocol Security
3 | description: Understanding Bifrost Protocol Security
4 | ---
5 |
6 | ## Bifrost security model
7 | In the world of DeFi, Liquid Staking has surpassed decentralized exchanges (DEXs) to achieve the highest Total Value Locked (TVL). Liquid Staking Token (LST) protocols manage substantial assets, significantly impacting the security and functionality of their underlying Proof-of-Stake (PoS) chains.
8 |
9 | [Bifrost's crosschain architecture](https://bifrost.io/blog/a-deep-dive-into-crosschain-architecture-and-slpx) enhances the interoperability and efficiency of DeFi applications. However, effective cross-chain communication and seamless user experiences require a robust security framework. Bifrost addresses this need with a comprehensive security model that protects staked assets and maintains network integrity.
10 |
11 | ## Key Aspects of Bifrost's Security Model
12 |
13 | ### Polkadot's Shared Security
14 | The Bifrost Polkadot and Bifrost Kusama chains are parachains of Polkadot and Kusama, respectively. **Their security and resistance to reorganization are protected by the relay chain.**
15 |
16 | As widely known, Polkadot employs a shared architecture where the relay chain randomly assigns validators to parachains and verifies their blocks. The blocks of the relay chain will include the blocks of the parachain, providing data availability for the parachains. This mechanism is the foundation of Polkadot's shared security.
17 |
18 | Parachains do not require running validators, nor do they need to increase validator numbers to promote decentralization. Instead, they operate with a limited number of collator nodes. The role of collator nodes functions similarly to the Sequencer in Ethereum L2, which is responsible for collecting and ordering transactions in the parachains. The number of collators does not need to be excessive; it only needs to ensure network availability and make transactions less prone to censorship. Currently, the Bifrost Polkadot chain has over 32 collator nodes, which is more than sufficient to maintain robust network performance.
19 |
20 | ### Crosschain Communication Based on XCMP and XCM
21 |
22 | In Bifrost's cross-chain architecture, there's a significant involvement of cross-chain communication. The security of cross-chain bridges is a well-known challenge in the blockchain space. So, how does Bifrost ensure the security of cross-chain communication? The answer lies in the cross-chain communication mechanism of Polkadot. Polkadot aims not only to create a platform for shared security but also to achieve seamless cross-chain interoperability. Polkadot accomplishes this through the Cross-Chain Message Passing (XCMP) protocol and the Cross-Consensus Message (XCM) format.
23 |
24 | ### How XCMP works
25 |
26 | - Cross-chain messages enter the Egress (exit queue) of the sending chain.
27 | - Collators of the target chain collect these messages from the Egress of other chains and place them into their Ingress (entry queue).
28 |
29 | - Messages are included in the relay chain's blocks and finalized, then executed by the target chain.
30 |
31 | In summary, XCMP ensures fast, secure, ordered, and cost-effective cross-chain message delivery between Polkadot parachains.
32 |
33 | ### How XCM works:
34 | - XCM is a message format for cross-chain communication between Polkadot parachains.
35 | - XCM messages are included in the relay chain's blocks and finalized, then executed by the target chain.
36 | - XCM messages are executed by the target chain's consensus mechanism.
37 |
38 | In summary, XCM ensures fast, secure, ordered, and cost-effective cross-chain message delivery between Polkadot parachains.
39 |
40 | 
41 |
42 | When XCMP is used for communication between parachains, XCM is used to ensure that these chains can understand each other's messages and know how to execute them. Polkadot's vision for XCM extends beyond the cross-chain communication within Polkadot. It aims to be adopted by a broader range of heterogeneous blockchains. Therefore, it is named the Cross-Consensus Message format.
43 |
44 | For a more in-depth interpretation of the operational mechanisms of XCMP and XCM, Bifrost provides detailed insights in this article: [How Bifrost Supports vMOVR and vGLMR Based on XCM](https://bifrost.io/blog/how-bifrost-supports-v-movr-and-v-glmr-based-on-xcm).
45 |
46 | However, Bifrost also acknowledges that heterogeneous cross-chain infrastructure is currently not mature. Therefore, it has not opted for a radical approach to fully implement the cross-chain architecture but instead retained the SLP modules on Ethereum and Kusama. Nevertheless, as the cryptocurrency industry develops, secure and reliable heterogeneous cross-chain solutions are expected to emerge.
47 |
48 | ### Non-custodial Mechanism and Rigorously Audited Code
49 |
50 | Bifrost adopts a fully decentralized approach to manage staked assets. All processes are completed through decentralized contracts or runtime, without any human intervention and the need to trust any third party, including the Bifrost development team.
51 |
52 | 
53 |
54 | Furthermore, Bifrost's on-chain code is open source, allowing for public scrutiny and vulnerability reporting. The code has been rigorously audited by multiple security firms, including Beosin, Slowmist, and TokenInsight. Since its inception in 2019, Bifrost has maintained a flawless security record, demonstrating its resilience in terms of code security.
55 |
56 | ### Secure Validator Set and Slash Protection
57 | Apart from the risks of intentional misconduct and code vulnerabilities, users' staked assets may also face the risk of slashing. Staked assets essentially serve as collateral for running nodes. If a node engages in improper behavior that disrupts the network, a portion or all of the malicious node's staked funds may be slashed by the network.
58 |
59 | An LST protocol that selects validators irresponsibly can expose LST asset holders to slashing losses, which could manifest as a decrease in the exchange rate between LST and the original token.
60 |
61 | To minimize users' exposure to slashing losses, Bifrost has implemented several measures:
62 |
63 | - **Rigorous Validator Selection**: Bifrost evaluates validators not only based on profitability but also by considering factors such as the node's leverage ratio (self-staking ratio) and historical credibility. Detailed criteria and methods for selecting validators will be discussed in the next chapter.
64 | - **Proactive Node Switching**: In the event of a slashing risk, Bifrost can immediately switch nodes to prevent further losses, a capability that individual stakers typically lack.
65 | - **vToken Vault**: Bifrost has established an insurance pool called the vToken Vault, allocating 5% of the protocol's income to it. If slashing occurs, this pool compensates users for their losses. If no slashing occurs, the amount in the vToken Vault accumulates over time. The more funds accumulated, the stronger the compensation capability.
66 |
67 | For a more detailed explanation of how Bifrost distributes, mitigates, and compensates for slashing risks, refer to [How Bifrost provides an insurance mechanism for vToken holders against the Slash risk](https://bifrost.io/blog/how-bifrost-provides-an-insurance-mechanism-for-v-token-holders-against-the-slash-risk).
--------------------------------------------------------------------------------
/content/docs/integration/base.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Base
3 | description: Integrate SLPx protocol on Base
4 | ---
5 |
6 | ## Getting started
7 |
8 | Make sure you add RPC for Moonbeam. Information can be obtained from [chainlist.org](https://chainlist.org/?search=moonbeam)
9 |
10 | Or manual input with the information below
11 | | Name | Value |
12 | |---|---|
13 | | Network Name | Soneium Network |
14 | | Description | The public mainnet for Soneium Network. |
15 | | Network URL | https://soneium.org/ |
16 | | Explorer URL | https://soneium.blockscout.com/ |
17 | | RPC URL | https://rpc.soneium.org/ |
18 | | Chain ID | 1868 |
19 | | Currency Symbol | ETH |
20 |
21 |
22 | ### `xcASTR` token
23 |
24 | | Name | Value |
25 | |---|---|
26 | | Address | [0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf](https://moonscan.io/address/0xffffffffa893ad19e540e172c10d78d4d479b5cf) |
27 | | Name | xcASTR |
28 | | Symbol | `xcASTR` |
29 | | Decimals | 18 |
30 |
31 |
32 | ### `MoonbeamSlpx.sol` contract
33 |
34 | | Name | Value |
35 | |---|---|
36 | | Address | [0xF1d4797E51a4640a76769A50b57abE7479ADd3d8](https://moonscan.io/address/0xF1d4797E51a4640a76769A50b57abE7479ADd3d8) |
37 | | Source code | [MoonbeamSlpx.sol](https://github.com/bifrost-io/slpx-contracts/blob/main/contracts/MoonbeamSlpx.sol) |
38 | | ABI | [MoonbeamSlpx.json](https://github.com/bifrost-io/slpx-contracts/blob/main/deployments/moonbeam/MoonbeamSlpx.json) |
39 |
40 | ## Integration
41 |
42 | MoonbeamSLPx contract does not support atomic contract calls. That means you can't integrate within your contract logic. The reason are as follows:
43 | - there is a wait time of about 45 to 60 to receive the `vAsset` token.
44 |
45 | However, you can still interact with the contract directly from the frontend or use another contract but the call is structured at the end of the logic.
46 |
47 | There are 2 main functions you use to integrate with `MoonbeamSlpx`:
48 |
49 | `addressToAssetInfo` (derived from the public mapping `addressToAssetInfo`)
50 | ```solidity
51 | function addressToAssetInfo(address assetAddress) public view returns (currencyId bytes2, operationalMin uint256)
52 | ```
53 |
54 | Sample call
55 |
56 | ```solidity
57 | MoonbeamSlpx.addressToAssetInfo(0x0000000000000000000000000000000000000802)
58 | ```
59 |
60 | Sample return
61 |
62 | ```bash
63 | currencyId bytes2 : 0x0801
64 | operationalMin uint256 : 5000000000000000000
65 | ```
66 |
67 |
68 |
69 | `create_order`
70 | ```solidity
71 | /**
72 | * @dev Create order to mint vAsset or redeem vAsset on bifrost chain
73 | * @param assetAddress The address of the asset to mint or redeem
74 | * @param amount The amount of the asset to mint or redeem
75 | * @param dest_chain_id When order is executed on Bifrost, Asset/vAsset will be transferred to this chain
76 | * @param receiver The receiver address on the destination chain, 20 bytes for EVM, 32 bytes for Substrate
77 | * @param remark The remark of the order, less than 32 bytes. For example, "OmniLS"
78 | * @param channel_id The channel id of the order, you can set it. Bifrost chain will use it to share reward.
79 | **/
80 | function create_order(
81 | address assetAddress,
82 | uint128 amount,
83 | uint64 dest_chain_id,
84 | bytes memory receiver,
85 | string memory remark,
86 | uint32 channel_id
87 | ) external payable;
88 | ```
89 |
90 | | Variable | Input value | Definition |
91 | |---|---|---|
92 | | `address assetAddress` | a valid Moonbeam token contract address | Address of different tokens on Moonbeam |
93 | | `uint128 amount` | `uint128` | Amount of tokens to mint or redeem |
94 | | `uint64 dest_chain_id` | `1284` | Chain ID of Moonbeam |
95 | | `bytes memory receiver` | a valid Moonbeam address | Asset receiver address on the destination chain, 20 bytes address for EVM |
96 | | `string memory remark` | `string` of less than 32 bytes | A string used to identify the order |
97 | | `uint32 channel_id` | `uint32` | Channel ID of the order. Used for the Bifrost Protocol Revenue Sharing Program (RSP). You can set it if you have one. Check [here](https://docs.bifrost.io/for-partners/reward-share-program-rsp) to learn more |
98 |
99 |
100 | **Token address list**
101 |
102 | | Token | Address |
103 | |---|---|
104 | | `xcDOT` | `0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080` |
105 | | `xcASTR` | `0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf` |
106 | | `GLMR` | `0x0000000000000000000000000000000000000802` |
107 |
108 |
109 | **Asset Info List**
110 |
111 | | Token | currencyId | operationalMin |
112 | |---|---|---|
113 | | `xcDOT` | `0x0800` | 10000000000 (`10_000_000_000`) |
114 | | `xcASTR` | `0x0803` | 5000000000000000000 (`5_000_000_000_000_000_000`) |
115 | | `GLMR` | `0x0801` | 5000000000000000000 (`5_000_000_000_000_000_000`) |
116 |
117 | **Waiting time**
118 |
119 | Then wait for 45 to 60 seconds after transaction confirmation to receive the `vAsset` token in the caller address.
120 |
121 | ### Example Wagmi integration
122 |
123 | `addressToAssetInfo`
124 |
125 | ```ts
126 | const { data: assetInfo } = useReadContract({
127 | ...wagmiContractConfig,
128 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
129 | abi: moonbeamSLPxAbi,
130 | functionName: "addressToAssetInfo",
131 | args: ["0x0000000000000000000000000000000000000802"],
132 | });
133 | console.log("assetInfo", assetInfo);
134 |
135 | // Output: assetInfo { currencyId: '0x0801', operationalMin: 5000000000000000000n }
136 | ```
137 |
138 | `create_order`
139 |
140 | **for ERC20 token**
141 | ```ts
142 | const {
143 | data: hash,
144 | error,
145 | isPending,
146 | writeContract
147 | } = useWriteContract()
148 |
149 | async function approveLstContract() {
150 | writeContract({
151 | account: currentAddress, // connected address
152 | address: "0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080",
153 | abi: erc20Abi,
154 | functionName: "approve",
155 | args: [
156 | "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
157 | parseUnits(1, 10), // 1 xcDOT is operationalMin and 10 is the token decimals
158 | ],
159 | })
160 | }
161 |
162 | async function mintLst() {
163 | writeContract({
164 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
165 | abi: moonbeamSLPxAbi,
166 | functionName: "create_order",
167 | args: [
168 | "0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080", // xcDOT token address
169 | parseUnits(1, 10), // amount
170 | 1284, // Moonbeam chain id
171 | receiverAddress, // receiver
172 | "bifrost", // sample remark
173 | 0, // sample channel_id
174 | ],
175 | })
176 | }
177 |
178 | const { isLoading: isConfirming, isSuccess: isConfirmed } =
179 | useWaitForTransactionReceipt({
180 | hash,
181 | })
182 | ```
183 |
184 | **for GLMR token**
185 | ```ts
186 | const {
187 | data: hash,
188 | error,
189 | isPending,
190 | writeContract
191 | } = useWriteContract()
192 |
193 | async function mintLst() {
194 | writeContract({
195 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
196 | abi: moonbeamSLPxAbi,
197 | functionName: "create_order",
198 | args: [
199 | "0x0000000000000000000000000000000000000802", // xcDOT token address
200 | parseUnits(5, 18), // amount
201 | 1284, // Moonbeam chain id
202 | receiverAddress, // receiver
203 | "bifrost", // sample remark
204 | 0, // sample channel_id
205 | ],
206 | value: parseUnits(5, 18) // 5 GLMR
207 | })
208 | }
209 |
210 | const { isLoading: isConfirming, isSuccess: isConfirmed } =
211 | useWaitForTransactionReceipt({
212 | hash,
213 | })
214 | ```
--------------------------------------------------------------------------------
/content/docs/integration/soneium.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Soneium
3 | description: Integrate SLPx protocol on Soneium
4 | ---
5 |
6 | ## Getting started
7 |
8 | Make sure you add RPC for Moonbeam. Information can be obtained from [chainlist.org](https://chainlist.org/?search=moonbeam)
9 |
10 | Or manual input with the information below
11 | | Name | Value |
12 | |---|---|
13 | | Network Name | Soneium Network |
14 | | Description | The public mainnet for Soneium Network. |
15 | | Network URL | https://soneium.org/ |
16 | | Explorer URL | https://soneium.blockscout.com/ |
17 | | RPC URL | https://rpc.soneium.org/ |
18 | | Chain ID | 1868 |
19 | | Currency Symbol | ETH |
20 |
21 |
22 | ### `xcASTR` token
23 |
24 | | Name | Value |
25 | |---|---|
26 | | Address | [0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf](https://moonscan.io/address/0xffffffffa893ad19e540e172c10d78d4d479b5cf) |
27 | | Name | xcASTR |
28 | | Symbol | `xcASTR` |
29 | | Decimals | 18 |
30 |
31 |
32 | ### `MoonbeamSlpx.sol` contract
33 |
34 | | Name | Value |
35 | |---|---|
36 | | Address | [0xF1d4797E51a4640a76769A50b57abE7479ADd3d8](https://moonscan.io/address/0xF1d4797E51a4640a76769A50b57abE7479ADd3d8) |
37 | | Source code | [MoonbeamSlpx.sol](https://github.com/bifrost-io/slpx-contracts/blob/main/contracts/MoonbeamSlpx.sol) |
38 | | ABI | [MoonbeamSlpx.json](https://github.com/bifrost-io/slpx-contracts/blob/main/deployments/moonbeam/MoonbeamSlpx.json) |
39 |
40 | ## Integration
41 |
42 | MoonbeamSLPx contract does not support atomic contract calls. That means you can't integrate within your contract logic. The reason are as follows:
43 | - there is a wait time of about 45 to 60 to receive the `vAsset` token.
44 |
45 | However, you can still interact with the contract directly from the frontend or use another contract but the call is structured at the end of the logic.
46 |
47 | There are 2 main functions you use to integrate with `MoonbeamSlpx`:
48 |
49 | `addressToAssetInfo` (derived from the public mapping `addressToAssetInfo`)
50 | ```solidity
51 | function addressToAssetInfo(address assetAddress) public view returns (currencyId bytes2, operationalMin uint256)
52 | ```
53 |
54 | Sample call
55 |
56 | ```solidity
57 | MoonbeamSlpx.addressToAssetInfo(0x0000000000000000000000000000000000000802)
58 | ```
59 |
60 | Sample return
61 |
62 | ```bash
63 | currencyId bytes2 : 0x0801
64 | operationalMin uint256 : 5000000000000000000
65 | ```
66 |
67 |
68 |
69 | `create_order`
70 | ```solidity
71 | /**
72 | * @dev Create order to mint vAsset or redeem vAsset on bifrost chain
73 | * @param assetAddress The address of the asset to mint or redeem
74 | * @param amount The amount of the asset to mint or redeem
75 | * @param dest_chain_id When order is executed on Bifrost, Asset/vAsset will be transferred to this chain
76 | * @param receiver The receiver address on the destination chain, 20 bytes for EVM, 32 bytes for Substrate
77 | * @param remark The remark of the order, less than 32 bytes. For example, "OmniLS"
78 | * @param channel_id The channel id of the order, you can set it. Bifrost chain will use it to share reward.
79 | **/
80 | function create_order(
81 | address assetAddress,
82 | uint128 amount,
83 | uint64 dest_chain_id,
84 | bytes memory receiver,
85 | string memory remark,
86 | uint32 channel_id
87 | ) external payable;
88 | ```
89 |
90 | | Variable | Input value | Definition |
91 | |---|---|---|
92 | | `address assetAddress` | a valid Moonbeam token contract address | Address of different tokens on Moonbeam |
93 | | `uint128 amount` | `uint128` | Amount of tokens to mint or redeem |
94 | | `uint64 dest_chain_id` | `1284` | Chain ID of Moonbeam |
95 | | `bytes memory receiver` | a valid Moonbeam address | Asset receiver address on the destination chain, 20 bytes address for EVM |
96 | | `string memory remark` | `string` of less than 32 bytes | A string used to identify the order |
97 | | `uint32 channel_id` | `uint32` | Channel ID of the order. Used for the Bifrost Protocol Revenue Sharing Program (RSP). You can set it if you have one. Check [here](https://docs.bifrost.io/for-partners/reward-share-program-rsp) to learn more |
98 |
99 |
100 | **Token address list**
101 |
102 | | Token | Address |
103 | |---|---|
104 | | `xcDOT` | `0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080` |
105 | | `xcASTR` | `0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf` |
106 | | `GLMR` | `0x0000000000000000000000000000000000000802` |
107 |
108 |
109 | **Asset Info List**
110 |
111 | | Token | currencyId | operationalMin |
112 | |---|---|---|
113 | | `xcDOT` | `0x0800` | 10000000000 (`10_000_000_000`) |
114 | | `xcASTR` | `0x0803` | 5000000000000000000 (`5_000_000_000_000_000_000`) |
115 | | `GLMR` | `0x0801` | 5000000000000000000 (`5_000_000_000_000_000_000`) |
116 |
117 | **Waiting time**
118 |
119 | Then wait for 45 to 60 seconds after transaction confirmation to receive the `vAsset` token in the caller address.
120 |
121 | ### Example Wagmi integration
122 |
123 | `addressToAssetInfo`
124 |
125 | ```ts
126 | const { data: assetInfo } = useReadContract({
127 | ...wagmiContractConfig,
128 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
129 | abi: moonbeamSLPxAbi,
130 | functionName: "addressToAssetInfo",
131 | args: ["0x0000000000000000000000000000000000000802"],
132 | });
133 | console.log("assetInfo", assetInfo);
134 |
135 | // Output: assetInfo { currencyId: '0x0801', operationalMin: 5000000000000000000n }
136 | ```
137 |
138 | `create_order`
139 |
140 | **for ERC20 token**
141 | ```ts
142 | const {
143 | data: hash,
144 | error,
145 | isPending,
146 | writeContract
147 | } = useWriteContract()
148 |
149 | async function approveLstContract() {
150 | writeContract({
151 | account: currentAddress, // connected address
152 | address: "0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080",
153 | abi: erc20Abi,
154 | functionName: "approve",
155 | args: [
156 | "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
157 | parseUnits(1, 10), // 1 xcDOT is operationalMin and 10 is the token decimals
158 | ],
159 | })
160 | }
161 |
162 | async function mintLst() {
163 | writeContract({
164 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
165 | abi: moonbeamSLPxAbi,
166 | functionName: "create_order",
167 | args: [
168 | "0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080", // xcDOT token address
169 | parseUnits(1, 10), // amount
170 | 1284, // Moonbeam chain id
171 | receiverAddress, // receiver
172 | "bifrost", // sample remark
173 | 0, // sample channel_id
174 | ],
175 | })
176 | }
177 |
178 | const { isLoading: isConfirming, isSuccess: isConfirmed } =
179 | useWaitForTransactionReceipt({
180 | hash,
181 | })
182 | ```
183 |
184 | **for GLMR token**
185 | ```ts
186 | const {
187 | data: hash,
188 | error,
189 | isPending,
190 | writeContract
191 | } = useWriteContract()
192 |
193 | async function mintLst() {
194 | writeContract({
195 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
196 | abi: moonbeamSLPxAbi,
197 | functionName: "create_order",
198 | args: [
199 | "0x0000000000000000000000000000000000000802", // xcDOT token address
200 | parseUnits(5, 18), // amount
201 | 1284, // Moonbeam chain id
202 | receiverAddress, // receiver
203 | "bifrost", // sample remark
204 | 0, // sample channel_id
205 | ],
206 | value: parseUnits(5, 18) // 5 GLMR
207 | })
208 | }
209 |
210 | const { isLoading: isConfirming, isSuccess: isConfirmed } =
211 | useWaitForTransactionReceipt({
212 | hash,
213 | })
214 | ```
--------------------------------------------------------------------------------
/content/docs/integration/arbitrum.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Arbitrum
3 | description: Integrate SLPx protocol on Arbitrum
4 | ---
5 |
6 | ## Getting started
7 |
8 | Make sure you add RPC for Moonbeam. Information can be obtained from [chainlist.org](https://chainlist.org/?search=moonbeam)
9 |
10 | Or manual input with the information below
11 | | Name | Value |
12 | |---|---|
13 | | Network Name | Soneium Network |
14 | | Description | The public mainnet for Soneium Network. |
15 | | Network URL | https://soneium.org/ |
16 | | Explorer URL | https://soneium.blockscout.com/ |
17 | | RPC URL | https://rpc.soneium.org/ |
18 | | Chain ID | 1868 |
19 | | Currency Symbol | ETH |
20 |
21 |
22 | ### `xcASTR` token
23 |
24 | | Name | Value |
25 | |---|---|
26 | | Address | [0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf](https://moonscan.io/address/0xffffffffa893ad19e540e172c10d78d4d479b5cf) |
27 | | Name | xcASTR |
28 | | Symbol | `xcASTR` |
29 | | Decimals | 18 |
30 |
31 |
32 | ### `MoonbeamSlpx.sol` contract
33 |
34 | | Name | Value |
35 | |---|---|
36 | | Address | [0xF1d4797E51a4640a76769A50b57abE7479ADd3d8](https://moonscan.io/address/0xF1d4797E51a4640a76769A50b57abE7479ADd3d8) |
37 | | Source code | [MoonbeamSlpx.sol](https://github.com/bifrost-io/slpx-contracts/blob/main/contracts/MoonbeamSlpx.sol) |
38 | | ABI | [MoonbeamSlpx.json](https://github.com/bifrost-io/slpx-contracts/blob/main/deployments/moonbeam/MoonbeamSlpx.json) |
39 |
40 | ## Integration
41 |
42 | MoonbeamSLPx contract does not support atomic contract calls. That means you can't integrate within your contract logic. The reason are as follows:
43 | - there is a wait time of about 45 to 60 to receive the `vAsset` token.
44 |
45 | However, you can still interact with the contract directly from the frontend or use another contract but the call is structured at the end of the logic.
46 |
47 | There are 2 main functions you use to integrate with `MoonbeamSlpx`:
48 |
49 | `addressToAssetInfo` (derived from the public mapping `addressToAssetInfo`)
50 | ```solidity
51 | function addressToAssetInfo(address assetAddress) public view returns (currencyId bytes2, operationalMin uint256)
52 | ```
53 |
54 | Sample call
55 |
56 | ```solidity
57 | MoonbeamSlpx.addressToAssetInfo(0x0000000000000000000000000000000000000802)
58 | ```
59 |
60 | Sample return
61 |
62 | ```bash
63 | currencyId bytes2 : 0x0801
64 | operationalMin uint256 : 5000000000000000000
65 | ```
66 |
67 |
68 |
69 | `create_order`
70 | ```solidity
71 | /**
72 | * @dev Create order to mint vAsset or redeem vAsset on bifrost chain
73 | * @param assetAddress The address of the asset to mint or redeem
74 | * @param amount The amount of the asset to mint or redeem
75 | * @param dest_chain_id When order is executed on Bifrost, Asset/vAsset will be transferred to this chain
76 | * @param receiver The receiver address on the destination chain, 20 bytes for EVM, 32 bytes for Substrate
77 | * @param remark The remark of the order, less than 32 bytes. For example, "OmniLS"
78 | * @param channel_id The channel id of the order, you can set it. Bifrost chain will use it to share reward.
79 | **/
80 | function create_order(
81 | address assetAddress,
82 | uint128 amount,
83 | uint64 dest_chain_id,
84 | bytes memory receiver,
85 | string memory remark,
86 | uint32 channel_id
87 | ) external payable;
88 | ```
89 |
90 | | Variable | Input value | Definition |
91 | |---|---|---|
92 | | `address assetAddress` | a valid Moonbeam token contract address | Address of different tokens on Moonbeam |
93 | | `uint128 amount` | `uint128` | Amount of tokens to mint or redeem |
94 | | `uint64 dest_chain_id` | `1284` | Chain ID of Moonbeam |
95 | | `bytes memory receiver` | a valid Moonbeam address | Asset receiver address on the destination chain, 20 bytes address for EVM |
96 | | `string memory remark` | `string` of less than 32 bytes | A string used to identify the order |
97 | | `uint32 channel_id` | `uint32` | Channel ID of the order. Used for the Bifrost Protocol Revenue Sharing Program (RSP). You can set it if you have one. Check [here](https://docs.bifrost.io/for-partners/reward-share-program-rsp) to learn more |
98 |
99 |
100 | **Token address list**
101 |
102 | | Token | Address |
103 | |---|---|
104 | | `xcDOT` | `0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080` |
105 | | `xcASTR` | `0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf` |
106 | | `GLMR` | `0x0000000000000000000000000000000000000802` |
107 |
108 |
109 | **Asset Info List**
110 |
111 | | Token | currencyId | operationalMin |
112 | |---|---|---|
113 | | `xcDOT` | `0x0800` | 10000000000 (`10_000_000_000`) |
114 | | `xcASTR` | `0x0803` | 5000000000000000000 (`5_000_000_000_000_000_000`) |
115 | | `GLMR` | `0x0801` | 5000000000000000000 (`5_000_000_000_000_000_000`) |
116 |
117 | **Waiting time**
118 |
119 | Then wait for 45 to 60 seconds after transaction confirmation to receive the `vAsset` token in the caller address.
120 |
121 | ### Example Wagmi integration
122 |
123 | `addressToAssetInfo`
124 |
125 | ```ts
126 | const { data: assetInfo } = useReadContract({
127 | ...wagmiContractConfig,
128 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
129 | abi: moonbeamSLPxAbi,
130 | functionName: "addressToAssetInfo",
131 | args: ["0x0000000000000000000000000000000000000802"],
132 | });
133 | console.log("assetInfo", assetInfo);
134 |
135 | // Output: assetInfo { currencyId: '0x0801', operationalMin: 5000000000000000000n }
136 | ```
137 |
138 | `create_order`
139 |
140 | **for ERC20 token**
141 | ```ts
142 | const {
143 | data: hash,
144 | error,
145 | isPending,
146 | writeContract
147 | } = useWriteContract()
148 |
149 | async function approveLstContract() {
150 | writeContract({
151 | account: currentAddress, // connected address
152 | address: "0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080",
153 | abi: erc20Abi,
154 | functionName: "approve",
155 | args: [
156 | "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
157 | parseUnits(1, 10), // 1 xcDOT is operationalMin and 10 is the token decimals
158 | ],
159 | })
160 | }
161 |
162 | async function mintLst() {
163 | writeContract({
164 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
165 | abi: moonbeamSLPxAbi,
166 | functionName: "create_order",
167 | args: [
168 | "0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080", // xcDOT token address
169 | parseUnits(1, 10), // amount
170 | 1284, // Moonbeam chain id
171 | receiverAddress, // receiver
172 | "bifrost", // sample remark
173 | 0, // sample channel_id
174 | ],
175 | })
176 | }
177 |
178 | const { isLoading: isConfirming, isSuccess: isConfirmed } =
179 | useWaitForTransactionReceipt({
180 | hash,
181 | })
182 | ```
183 |
184 | **for GLMR token**
185 | ```ts
186 | const {
187 | data: hash,
188 | error,
189 | isPending,
190 | writeContract
191 | } = useWriteContract()
192 |
193 | async function mintLst() {
194 | writeContract({
195 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
196 | abi: moonbeamSLPxAbi,
197 | functionName: "create_order",
198 | args: [
199 | "0x0000000000000000000000000000000000000802", // xcDOT token address
200 | parseUnits(5, 18), // amount
201 | 1284, // Moonbeam chain id
202 | receiverAddress, // receiver
203 | "bifrost", // sample remark
204 | 0, // sample channel_id
205 | ],
206 | value: parseUnits(5, 18) // 5 GLMR
207 | })
208 | }
209 |
210 | const { isLoading: isConfirming, isSuccess: isConfirmed } =
211 | useWaitForTransactionReceipt({
212 | hash,
213 | })
214 | ```
--------------------------------------------------------------------------------
/content/docs/integration/bnbchain.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: BNB Chain
3 | description: Integrate SLPx protocol on BNB Chain
4 | ---
5 |
6 | ## Getting started
7 |
8 | Make sure you add RPC for Moonbeam. Information can be obtained from [chainlist.org](https://chainlist.org/?search=moonbeam)
9 |
10 | Or manual input with the information below
11 | | Name | Value |
12 | |---|---|
13 | | Network Name | Soneium Network |
14 | | Description | The public mainnet for Soneium Network. |
15 | | Network URL | https://soneium.org/ |
16 | | Explorer URL | https://soneium.blockscout.com/ |
17 | | RPC URL | https://rpc.soneium.org/ |
18 | | Chain ID | 1868 |
19 | | Currency Symbol | ETH |
20 |
21 |
22 | ### `xcASTR` token
23 |
24 | | Name | Value |
25 | |---|---|
26 | | Address | [0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf](https://moonscan.io/address/0xffffffffa893ad19e540e172c10d78d4d479b5cf) |
27 | | Name | xcASTR |
28 | | Symbol | `xcASTR` |
29 | | Decimals | 18 |
30 |
31 |
32 | ### `MoonbeamSlpx.sol` contract
33 |
34 | | Name | Value |
35 | |---|---|
36 | | Address | [0xF1d4797E51a4640a76769A50b57abE7479ADd3d8](https://moonscan.io/address/0xF1d4797E51a4640a76769A50b57abE7479ADd3d8) |
37 | | Source code | [MoonbeamSlpx.sol](https://github.com/bifrost-io/slpx-contracts/blob/main/contracts/MoonbeamSlpx.sol) |
38 | | ABI | [MoonbeamSlpx.json](https://github.com/bifrost-io/slpx-contracts/blob/main/deployments/moonbeam/MoonbeamSlpx.json) |
39 |
40 | ## Integration
41 |
42 | MoonbeamSLPx contract does not support atomic contract calls. That means you can't integrate within your contract logic. The reason are as follows:
43 | - there is a wait time of about 45 to 60 to receive the `vAsset` token.
44 |
45 | However, you can still interact with the contract directly from the frontend or use another contract but the call is structured at the end of the logic.
46 |
47 | There are 2 main functions you use to integrate with `MoonbeamSlpx`:
48 |
49 | `addressToAssetInfo` (derived from the public mapping `addressToAssetInfo`)
50 | ```solidity
51 | function addressToAssetInfo(address assetAddress) public view returns (currencyId bytes2, operationalMin uint256)
52 | ```
53 |
54 | Sample call
55 |
56 | ```solidity
57 | MoonbeamSlpx.addressToAssetInfo(0x0000000000000000000000000000000000000802)
58 | ```
59 |
60 | Sample return
61 |
62 | ```bash
63 | currencyId bytes2 : 0x0801
64 | operationalMin uint256 : 5000000000000000000
65 | ```
66 |
67 |
68 |
69 | `create_order`
70 | ```solidity
71 | /**
72 | * @dev Create order to mint vAsset or redeem vAsset on bifrost chain
73 | * @param assetAddress The address of the asset to mint or redeem
74 | * @param amount The amount of the asset to mint or redeem
75 | * @param dest_chain_id When order is executed on Bifrost, Asset/vAsset will be transferred to this chain
76 | * @param receiver The receiver address on the destination chain, 20 bytes for EVM, 32 bytes for Substrate
77 | * @param remark The remark of the order, less than 32 bytes. For example, "OmniLS"
78 | * @param channel_id The channel id of the order, you can set it. Bifrost chain will use it to share reward.
79 | **/
80 | function create_order(
81 | address assetAddress,
82 | uint128 amount,
83 | uint64 dest_chain_id,
84 | bytes memory receiver,
85 | string memory remark,
86 | uint32 channel_id
87 | ) external payable;
88 | ```
89 |
90 | | Variable | Input value | Definition |
91 | |---|---|---|
92 | | `address assetAddress` | a valid Moonbeam token contract address | Address of different tokens on Moonbeam |
93 | | `uint128 amount` | `uint128` | Amount of tokens to mint or redeem |
94 | | `uint64 dest_chain_id` | `1284` | Chain ID of Moonbeam |
95 | | `bytes memory receiver` | a valid Moonbeam address | Asset receiver address on the destination chain, 20 bytes address for EVM |
96 | | `string memory remark` | `string` of less than 32 bytes | A string used to identify the order |
97 | | `uint32 channel_id` | `uint32` | Channel ID of the order. Used for the Bifrost Protocol Revenue Sharing Program (RSP). You can set it if you have one. Check [here](https://docs.bifrost.io/for-partners/reward-share-program-rsp) to learn more |
98 |
99 |
100 | **Token address list**
101 |
102 | | Token | Address |
103 | |---|---|
104 | | `xcDOT` | `0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080` |
105 | | `xcASTR` | `0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf` |
106 | | `GLMR` | `0x0000000000000000000000000000000000000802` |
107 |
108 |
109 | **Asset Info List**
110 |
111 | | Token | currencyId | operationalMin |
112 | |---|---|---|
113 | | `xcDOT` | `0x0800` | 10000000000 (`10_000_000_000`) |
114 | | `xcASTR` | `0x0803` | 5000000000000000000 (`5_000_000_000_000_000_000`) |
115 | | `GLMR` | `0x0801` | 5000000000000000000 (`5_000_000_000_000_000_000`) |
116 |
117 | **Waiting time**
118 |
119 | Then wait for 45 to 60 seconds after transaction confirmation to receive the `vAsset` token in the caller address.
120 |
121 | ### Example Wagmi integration
122 |
123 | `addressToAssetInfo`
124 |
125 | ```ts
126 | const { data: assetInfo } = useReadContract({
127 | ...wagmiContractConfig,
128 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
129 | abi: moonbeamSLPxAbi,
130 | functionName: "addressToAssetInfo",
131 | args: ["0x0000000000000000000000000000000000000802"],
132 | });
133 | console.log("assetInfo", assetInfo);
134 |
135 | // Output: assetInfo { currencyId: '0x0801', operationalMin: 5000000000000000000n }
136 | ```
137 |
138 | `create_order`
139 |
140 | **for ERC20 token**
141 | ```ts
142 | const {
143 | data: hash,
144 | error,
145 | isPending,
146 | writeContract
147 | } = useWriteContract()
148 |
149 | async function approveLstContract() {
150 | writeContract({
151 | account: currentAddress, // connected address
152 | address: "0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080",
153 | abi: erc20Abi,
154 | functionName: "approve",
155 | args: [
156 | "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
157 | parseUnits(1, 10), // 1 xcDOT is operationalMin and 10 is the token decimals
158 | ],
159 | })
160 | }
161 |
162 | async function mintLst() {
163 | writeContract({
164 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
165 | abi: moonbeamSLPxAbi,
166 | functionName: "create_order",
167 | args: [
168 | "0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080", // xcDOT token address
169 | parseUnits(1, 10), // amount
170 | 1284, // Moonbeam chain id
171 | receiverAddress, // receiver
172 | "bifrost", // sample remark
173 | 0, // sample channel_id
174 | ],
175 | })
176 | }
177 |
178 | const { isLoading: isConfirming, isSuccess: isConfirmed } =
179 | useWaitForTransactionReceipt({
180 | hash,
181 | })
182 | ```
183 |
184 | **for GLMR token**
185 | ```ts
186 | const {
187 | data: hash,
188 | error,
189 | isPending,
190 | writeContract
191 | } = useWriteContract()
192 |
193 | async function mintLst() {
194 | writeContract({
195 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
196 | abi: moonbeamSLPxAbi,
197 | functionName: "create_order",
198 | args: [
199 | "0x0000000000000000000000000000000000000802", // xcDOT token address
200 | parseUnits(5, 18), // amount
201 | 1284, // Moonbeam chain id
202 | receiverAddress, // receiver
203 | "bifrost", // sample remark
204 | 0, // sample channel_id
205 | ],
206 | value: parseUnits(5, 18) // 5 GLMR
207 | })
208 | }
209 |
210 | const { isLoading: isConfirming, isSuccess: isConfirmed } =
211 | useWaitForTransactionReceipt({
212 | hash,
213 | })
214 | ```
--------------------------------------------------------------------------------
/content/docs/integration/ethereum.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Ethereum
3 | description: Integrate SLPx protocol on Ethereum
4 | ---
5 |
6 | ## Getting started
7 |
8 | Make sure you add RPC for Moonbeam. Information can be obtained from [chainlist.org](https://chainlist.org/?search=moonbeam)
9 |
10 | Or manual input with the information below
11 | | Name | Value |
12 | |---|---|
13 | | Network Name | Soneium Network |
14 | | Description | The public mainnet for Soneium Network. |
15 | | Network URL | https://soneium.org/ |
16 | | Explorer URL | https://soneium.blockscout.com/ |
17 | | RPC URL | https://rpc.soneium.org/ |
18 | | Chain ID | 1868 |
19 | | Currency Symbol | ETH |
20 |
21 |
22 | ### `xcASTR` token
23 |
24 | | Name | Value |
25 | |---|---|
26 | | Address | [0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf](https://moonscan.io/address/0xffffffffa893ad19e540e172c10d78d4d479b5cf) |
27 | | Name | xcASTR |
28 | | Symbol | `xcASTR` |
29 | | Decimals | 18 |
30 |
31 |
32 | ### `MoonbeamSlpx.sol` contract
33 |
34 | | Name | Value |
35 | |---|---|
36 | | Address | [0xF1d4797E51a4640a76769A50b57abE7479ADd3d8](https://moonscan.io/address/0xF1d4797E51a4640a76769A50b57abE7479ADd3d8) |
37 | | Source code | [MoonbeamSlpx.sol](https://github.com/bifrost-io/slpx-contracts/blob/main/contracts/MoonbeamSlpx.sol) |
38 | | ABI | [MoonbeamSlpx.json](https://github.com/bifrost-io/slpx-contracts/blob/main/deployments/moonbeam/MoonbeamSlpx.json) |
39 |
40 | ## Integration
41 |
42 | MoonbeamSLPx contract does not support atomic contract calls. That means you can't integrate within your contract logic. The reason are as follows:
43 | - there is a wait time of about 45 to 60 to receive the `vAsset` token.
44 |
45 | However, you can still interact with the contract directly from the frontend or use another contract but the call is structured at the end of the logic.
46 |
47 | There are 2 main functions you use to integrate with `MoonbeamSlpx`:
48 |
49 | `addressToAssetInfo` (derived from the public mapping `addressToAssetInfo`)
50 | ```solidity
51 | function addressToAssetInfo(address assetAddress) public view returns (currencyId bytes2, operationalMin uint256)
52 | ```
53 |
54 | Sample call
55 |
56 | ```solidity
57 | MoonbeamSlpx.addressToAssetInfo(0x0000000000000000000000000000000000000802)
58 | ```
59 |
60 | Sample return
61 |
62 | ```bash
63 | currencyId bytes2 : 0x0801
64 | operationalMin uint256 : 5000000000000000000
65 | ```
66 |
67 |
68 |
69 | `create_order`
70 | ```solidity
71 | /**
72 | * @dev Create order to mint vAsset or redeem vAsset on bifrost chain
73 | * @param assetAddress The address of the asset to mint or redeem
74 | * @param amount The amount of the asset to mint or redeem
75 | * @param dest_chain_id When order is executed on Bifrost, Asset/vAsset will be transferred to this chain
76 | * @param receiver The receiver address on the destination chain, 20 bytes for EVM, 32 bytes for Substrate
77 | * @param remark The remark of the order, less than 32 bytes. For example, "OmniLS"
78 | * @param channel_id The channel id of the order, you can set it. Bifrost chain will use it to share reward.
79 | **/
80 | function create_order(
81 | address assetAddress,
82 | uint128 amount,
83 | uint64 dest_chain_id,
84 | bytes memory receiver,
85 | string memory remark,
86 | uint32 channel_id
87 | ) external payable;
88 | ```
89 |
90 | | Variable | Input value | Definition |
91 | |---|---|---|
92 | | `address assetAddress` | a valid Moonbeam token contract address | Address of different tokens on Moonbeam |
93 | | `uint128 amount` | `uint128` | Amount of tokens to mint or redeem |
94 | | `uint64 dest_chain_id` | `1284` | Chain ID of Moonbeam |
95 | | `bytes memory receiver` | a valid Moonbeam address | Asset receiver address on the destination chain, 20 bytes address for EVM |
96 | | `string memory remark` | `string` of less than 32 bytes | A string used to identify the order |
97 | | `uint32 channel_id` | `uint32` | Channel ID of the order. Used for the Bifrost Protocol Revenue Sharing Program (RSP). You can set it if you have one. Check [here](https://docs.bifrost.io/for-partners/reward-share-program-rsp) to learn more |
98 |
99 |
100 | **Token address list**
101 |
102 | | Token | Address |
103 | |---|---|
104 | | `xcDOT` | `0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080` |
105 | | `xcASTR` | `0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf` |
106 | | `GLMR` | `0x0000000000000000000000000000000000000802` |
107 |
108 |
109 | **Asset Info List**
110 |
111 | | Token | currencyId | operationalMin |
112 | |---|---|---|
113 | | `xcDOT` | `0x0800` | 10000000000 (`10_000_000_000`) |
114 | | `xcASTR` | `0x0803` | 5000000000000000000 (`5_000_000_000_000_000_000`) |
115 | | `GLMR` | `0x0801` | 5000000000000000000 (`5_000_000_000_000_000_000`) |
116 |
117 | **Waiting time**
118 |
119 | Then wait for 45 to 60 seconds after transaction confirmation to receive the `vAsset` token in the caller address.
120 |
121 | ### Example Wagmi integration
122 |
123 | `addressToAssetInfo`
124 |
125 | ```ts
126 | const { data: assetInfo } = useReadContract({
127 | ...wagmiContractConfig,
128 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
129 | abi: moonbeamSLPxAbi,
130 | functionName: "addressToAssetInfo",
131 | args: ["0x0000000000000000000000000000000000000802"],
132 | });
133 | console.log("assetInfo", assetInfo);
134 |
135 | // Output: assetInfo { currencyId: '0x0801', operationalMin: 5000000000000000000n }
136 | ```
137 |
138 | `create_order`
139 |
140 | **for ERC20 token**
141 | ```ts
142 | const {
143 | data: hash,
144 | error,
145 | isPending,
146 | writeContract
147 | } = useWriteContract()
148 |
149 | async function approveLstContract() {
150 | writeContract({
151 | account: currentAddress, // connected address
152 | address: "0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080",
153 | abi: erc20Abi,
154 | functionName: "approve",
155 | args: [
156 | "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
157 | parseUnits(1, 10), // 1 xcDOT is operationalMin and 10 is the token decimals
158 | ],
159 | })
160 | }
161 |
162 | async function mintLst() {
163 | writeContract({
164 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
165 | abi: moonbeamSLPxAbi,
166 | functionName: "create_order",
167 | args: [
168 | "0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080", // xcDOT token address
169 | parseUnits(1, 10), // amount
170 | 1284, // Moonbeam chain id
171 | receiverAddress, // receiver
172 | "bifrost", // sample remark
173 | 0, // sample channel_id
174 | ],
175 | })
176 | }
177 |
178 | const { isLoading: isConfirming, isSuccess: isConfirmed } =
179 | useWaitForTransactionReceipt({
180 | hash,
181 | })
182 | ```
183 |
184 | **for GLMR token**
185 | ```ts
186 | const {
187 | data: hash,
188 | error,
189 | isPending,
190 | writeContract
191 | } = useWriteContract()
192 |
193 | async function mintLst() {
194 | writeContract({
195 | address: "0xF1d4797E51a4640a76769A50b57abE7479ADd3d8",
196 | abi: moonbeamSLPxAbi,
197 | functionName: "create_order",
198 | args: [
199 | "0x0000000000000000000000000000000000000802", // xcDOT token address
200 | parseUnits(5, 18), // amount
201 | 1284, // Moonbeam chain id
202 | receiverAddress, // receiver
203 | "bifrost", // sample remark
204 | 0, // sample channel_id
205 | ],
206 | value: parseUnits(5, 18) // 5 GLMR
207 | })
208 | }
209 |
210 | const { isLoading: isConfirming, isSuccess: isConfirmed } =
211 | useWaitForTransactionReceipt({
212 | hash,
213 | })
214 | ```
--------------------------------------------------------------------------------
/content/docs/vtokens/vbnc.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: vBNC
3 | description: Understanding vBNC
4 | ---
5 |
6 | ## What is vBNC?
7 |
8 | vBNC (voucher BNC) is a shadow token of staked BNC, with fully underlying BNC reserve and yield-bearing feature of BNC staking reward. Users can deposit BNC into Bifrost SLP protocol and get vBNC as return, vBNC can be traded in the open market or be redeemed back to BNC. Holding vBNC equals to holding the BNC staking position, staking rewards appreciate the exchange price of vBNC.
9 |
10 |
89 |
90 |
101 |
102 | #### Aggregator Module
103 |
104 | In order to improve the user experience of Redeem (more use of Swap for lightning swaps), this module is used to AMM (automatic market-maker) behavior and **simulate arbitrage to lower vDOT's Swap discount rate to a level similar to Redeem**. The profits generated in the process continue to carry out relevant market making operations/return to users. Through this module, the system can generate additional value to promote the healthy development of the SLP module.
105 |
106 | #### Polkadot Staking Era
107 |
108 | The settlement cycle of Polkadot staking operation is every 24 hours. At the end of the cycle, the **bonding / Unbonding operation** performed in the current cycle will be confirmed, and the **staking reward will be settled**. Committing operations at the end of the cycle is most efficient because the efficient execution of most operations in the cycle is processed uniformly at the end of the cycle.
109 |
110 | #### Bifrost SLP Address
111 |
112 | The DOT pledged by SLP and the related state are managed through the **sub-account of the parachain address**. Since there is an upper limit on the amount of DOT that can be pledged by an address under the condition of maximizing revenue, it should have the ability to configure multiple sub-addresses through on-chain governance.
113 |
114 | #### vDOT Rate
115 |
116 | SLP needs to issue Staking rewards to vDOT by raising the price of vDOT / DOT, **vDOT Rate = Staking total DOT / vDOT total issuance**. This exchange rate is the basis for a large number of operations of the system.
117 |
118 | ### How DOT Ready Pool works? (Adjusting vDOT Ratio)
119 |
120 | DOT Ready Pool communicate with Oracle by receiving update status and data on Polkadot relay-chain in each Era.
121 |
122 | #### In a New Era
123 |
124 | When a new Era message is received by SLP, the system mainly performs the following operations:
125 |
126 | * Send the cross-chain message withdraw Unbonded DOT and cross-chain transfer it to the DOT Ready Pool
127 | * Get the new staking reward data in current era, a part of which is directly transferred to the Aggregator module across the chain according to the Bifrost service commission rate.
128 | * After confirming that all current operations are successful, end the operation and issue a completion event
129 |
130 | #### At the End of an Era
131 |
132 | After receiving the Era End message, the system performs the following operations in sequence:
133 |
134 | * Match Redeem demand orders one by one for DOT redemption in the order of submission, delete the redeemed demand orders, and transfer DOT back to the corresponding address (Redeem orders support partial redemption)
135 | * When the Redeem match is over, judge the current DOT Ready Pool status:
136 |
137 | Oracle Multisig Address
91 | 92 | 1. bjbwPTJoPdtF96S2FEquuHoNv72T6KPzhayntu17Cr5g4BX 93 | 2. cEDk5LZS5UQtEEJnv1Sm1pDoTCDvv6rmChyF4A81sT9eCUZ 94 | 3. djJJCvG3s2Y4qZeTDS6RmmWdFSBHvcfTyJEDb2ARZKma9zA 95 | 4. eznovZYddE1KAvMc3ooBhvSS3JY6xFbii3QUCqpVEdnx5eg 96 | 5. gQCMN389RSi4gZwbG25agpyMPp1KQfPetteRU8TRd8tiQHu 97 | 98 | Multisig synthetic address: emmdmYNhx3PMyuaQZi98ZSNPw6PhFnhGnXyX2NqLwWazck2 99 | 100 |
90 |
91 |
102 |
103 | #### Aggregator Module
104 |
105 | In order to improve the user experience of Redeem (more use of Swap for lightning swaps), this module is used to AMM (automatic market-maker) behavior and **simulate arbitrage to lower vKSM's Swap discount rate to a level similar to Redeem**. The profits generated in the process continue to carry out relevant market making operations/return to users. Through this module, the system can generate additional value to promote the healthy development of the SLP module.
106 |
107 | #### Kusama Staking Era
108 |
109 | The settlement cycle of Kusama staking operation is every 6 hours. At the end of the cycle, the **bonding / Unbonding operation** performed in the current cycle will be confirmed, and the **staking reward will be settled**. Committing operations at the end of the cycle is most efficient because the efficient execution of most operations in the cycle is processed uniformly at the end of the cycle.
110 |
111 | #### Bifrost SLP Address
112 |
113 | The KSM pledged by SLP and the related state are managed through the **sub-account of the parachain address**. Since there is an upper limit on the amount of KSM that can be pledged by an address under the condition of maximizing revenue, it should have the ability to configure multiple sub-addresses through on-chain governance.
114 |
115 | #### vKSM Rate
116 |
117 | SLP needs to issue Staking rewards to vKSM by raising the price of vKSM / KSM, **vKSM Rate = Staking total KSM / vKSM total issuance**. This exchange rate is the basis for a large number of operations of the system.
118 |
119 | ### How KSM Ready Pool works? (Adjusting vKSM Ratio)
120 |
121 | KSM Ready Pool communicate with Oracle by receiving update status and data on Kusama relay-chain in each Era.
122 |
123 | #### In a New Era
124 |
125 | When a new Era message is received by SLP, the system mainly performs the following operations:
126 |
127 | * Send the cross-chain message withdraw Unbonded KSM and cross-chain transfer it to the KSM Ready Pool
128 | * Get the new staking reward data in current era, a part of which is directly transferred to the Aggregator module across the chain according to the Bifrost service commission rate.
129 | * After confirming that all current operations are successful, end the operation and issue a completion event
130 |
131 | #### In the End of an Era
132 |
133 | After receiving the Era End message, the system performs the following operations in sequence:
134 |
135 | * Match Redeem demand orders one by one for KSM redemption in the order of submission, delete the redeemed demand orders, and transfer KSM back to the corresponding address (Redeem orders support partial redemption)
136 | * When the Redeem match is over, judge the current KSM Ready Pool status:
137 |
138 | Oracle Multisig Address
92 | 93 | 1. bjbwPTJoPdtF96S2FEquuHoNv72T6KPzhayntu17Cr5g4BX 94 | 2. cEDk5LZS5UQtEEJnv1Sm1pDoTCDvv6rmChyF4A81sT9eCUZ 95 | 3. djJJCvG3s2Y4qZeTDS6RmmWdFSBHvcfTyJEDb2ARZKma9zA 96 | 4. eznovZYddE1KAvMc3ooBhvSS3JY6xFbii3QUCqpVEdnx5eg 97 | 5. gQCMN389RSi4gZwbG25agpyMPp1KQfPetteRU8TRd8tiQHu 98 | 99 | Multisig synthetic address: emmdmYNhx3PMyuaQZi98ZSNPw6PhFnhGnXyX2NqLwWazck2 100 | 101 || 地址 | 参与方 |
|---|---|
| Address | Parties |
| 0x4882328c14bb1a9a5c4F5E2B21bE345A72A1f638 | InfStones |
| 0x0620Ca0ca30c917aB62d119E5d91A9a954d31604 | LongHash |
| 0x146eE71e057e6B10eFB93AEdf631Fde6CbAED5E2 | Ankr |
| 0x4f62839ccD37c9a41999ceDB71cc9B4E8B2eBB97 | DFG |
| 0xdd4bB59E9088987CbEe31cC5a8e63cD8FEC12065 | Bifrost |