HomeDappGithub

vMANTA

What is vMANTA?

vMANTA (voucher MANTA) is a shadow token of staked MANTA, with fully underlying MANTA reserve and yield-bearing feature of MANTA staking reward. Users can deposit MANTA into Bifrost SLP protocol and get vMANTA as return, vMANTA can be traded in the open market or be redeemed back to MANTA. Holding vMANTA equals to holding the MANTA staking position, staking rewards appreciate the exchange price of vMANTA.

Staking rewards automatically add to the vMANTA exchange price, no manual claim. The longer vMANTA postion holding, the greater amount of MANTA will be exchanged back when redemption.

Why vMANTA?

Liquid Staking

The product allows users to delegate MANTA for liquid vToken, (vMANTA). vMANTA will keep receiving staking rewards and can continue to be used in Bifrost and Polkadot-based DeFi for additional rewards.

Automatically Staking rewards capturing without scenario limitations

SLP will issue Staking rewards to vMANTA by adjusting the price of vMANTA / MANTA upwards. vMANTA Rate = SLP Staking MANTA (SUM) / vMANTA Total Issuance.

Floating redemption period, vMANTA ≤ 168 hours

While Manta’s original chain Staking has a fixed revoke period, Bifrost SLP helps users to realize the possibility of early vMANTA redemption by matching the real-time vMANTA minting quantity with the redemption quantity at the protocol layer in form of a queue.

Higher Staking Yield

In the SLP protocol, the protocol screens verified nodes through governance (subsequently increasing with the overall staking volume) and adds multiple filters such as the number of nominees and history of blocks out to maximize the return of this verifier portfolio while ensuring that none of the nodes have experienced slashes.

Multi-environment Compatibility

vMANTA is one of Substrate assets in Bifrost parachain, by using the HRMP channels between Bifrost and others, it can be easily utilized in EVM, WASM and Substarte competiable parachains.

How it works?

vMANTA is minted by Bifrost SLP pallet, so firstly users have to call XCM cross chain transfer MANTA from Manta to Bifrost Parachain.

Mint vMANTA

  1. Users initiate a vMANTA mint order, SLP protocol transfers MANTA to MANTA Ready Pool (which is an order pool accumulates all mint and redeem orders), SLP mints vMANTA for users;

  2. MANTA Ready Pool matches Mint amount and Redeem amount;

  3. Oracle monitor matching results from MANTA Ready Pool and send messages to Manta-Bifrost SLP addresses;

  4. Bifrost SLP addresses execute Staking to SLP Manta Collator set, Oracle queries the successful messages and send them back to Bifrost MANTA Ready Pool, get ready for the next matching.

About SLP Oracle/backend service: The SLP backend service is using ⅘ multisig nodes, responsible for adjusting the exchange rate in each round, returning the due amount to the current redeem due user, checking the ledger, summarizing the pledge amount in a new round, and calling the corresponding SLP module function. In order to more flexibly handle the increase or decrease of users' pledge in each round, we will adopt a decentralized delegation relationship and a small-amount pledge strategy to increase the efficiency of the use of funds.

Redeem vMANTA

  1. Users initiate a vMANTA redeem orders to MANTA Ready Pool;

  2. MANTA Ready Pool matches Redeem amount and Mint amount, and dispatches the remaining MANTA to vMANTA redeem orders, SLP destroys the redeemed vMANTA amount;

  3. Oracle monitor redeem orders from Bifrost chain and send messages to Manta-Bifrost SLP addresses;

  4. Bifrost SLP addresses execute Redeem to SLP Manta collators set and send redeemed MANTA back to Bifrost parachain, Oracle queries all these messages and send them back to Bifrost MANTA Ready Pool, get ready for the next round matching.

MANTA Reward

The MANTA reward will be reinvested on Manta, and the Oracle will transmit the reward data to the MANTA Ready Pool to adjust the vMANTA exchange rate.

vMANTArate=(StakedMANTA+StakingReward)/vMANTAAllocationvMANTA rate=(StakedMANTA+StakingReward)/vMANTA Allocation

💡 Read more detailed info in the following sections.

SLP-vMANTA Technology Implementation

Overall operation process

The entire SLP protocol includes three parts, the Vtoken-Minting module, the SLP module, and the backend service.

The user can call the mint/redeem/rebond method of the VtokenMinting module through the front end to mint MANTA into vMANTA, or exchange vMANTA back to MANTA. During the period of holding vMANTA, users can enjoy staking benefits, which are reflected in the exchange rate of vMANTA to MANTA. If the user has new pledge amounts in the pool during the redeem period, the user will be able to experience the process of fast redemption, and the new pledge amount will be returned to the users in front of the redeem queue first.

The SLP module of Bifrost is responsible for communicating with the ParachainStaking module of the Manta chain by sending cross-chain messages to perform operations such as delegate, delegate_bond_more, schedule_delegator_bond_less, schedule_revoke_delegation, execute_delegation_request, cancel_delegation_request, schedule_leave_delegators, execute_leave_delegators, cancel_leave_delegators. The delegator account is generated by Bifrost's parachain address on the Manta chain, and the corresponding sub-account is generated by calling the as_derivative function of the utility module. All delegator and validator addresses are stored and used in the format of MultiLocation in the module.

Backend service function

The SLP backend service is responsible for adjusting the exchange rate in each round, returning the due amount to the current redeem due user, checking the ledger, summarizing the pledge amount in a new round, and calling the corresponding SLP module function. In order to more flexibly handle the increase or decrease of users' pledge in each round, we will adopt a decentralized delegation relationship and a small-amount pledge strategy to increase the efficiency of the use of funds.

At the start of Round

  1. Update round numbers

  2. Charge the custody fee, add interest (according to the dividend event, dividends before n+1 period), modify the exchange rate, and transfer the interest amount back to the exit account.

  3. Withdrawal of redemption due amount

  4. Repay the current due debt and transfer the remaining amount to the entry account for quick redemption.

  5. Query and compensate the reserve amount of handling fees for each operating account.

Before Round ends

  1. Transfer the excess amount in the entry account to a different delegate, and perform the pledge operation. When pledging, pay attention to check if the ranking is in the bottom delegation. If so, add the delegating amount, or transfer the amount to another collator.

  2. Check the ledger, warn and adjust accordingly if there are discrepancies.

Attention for staking operations:

  1. The staking amount is distributed among multiple delegation relationships of multiple delegates in a relatively even manner to facilitate each round of bond and redeem fund operations and improve the efficiency of fund use.

  2. Don't let the delegates fall into the bottom delegation group of collators. It is necessary to maintain a real-time top lowest value of collator. In theory, each account should try to keep a certain percentage higher than this value, such as 15%.

  3. When comparing the difference in the number of redeems between the Bifrost chain and the Manta chain, the number on the Manta side should be greater than or equal to the number on the Bifrost side

Vtoken-Minting module

The user can call the mint/redeem/rebond method of the VtokenMinting module through the front end to mint MANTA into vMANTA, or exchange vMANTA back to MANTA. During the period of holding vMANTA, users can enjoy staking benefits, which are reflected in the exchange rate of vMANTA to MANTA. If the user has new pledge amounts in the pool during the redeem period, the user will be able to experience the process of fast redemption, and the new pledge amount will be returned to the users in front of the redeem queue first.

Storages and Funtions

  1. Mint and Redeem Fees (universal for all tokens, set once is enough):

    • Format: Ratio

    • Type: Permill

    • Setting Function: set_fees

    • Value: 1000, 1000

    • Explanation: Both values are 0.1%. Since the unit is per mil, the value should be entered as 1000.

  2. Time to wait after user redemption:

    • Format: Round

    • Type: TimeUnit::Round(x)

    • Setting Function: set_unlock_duration

    • Value: 28

  3. Minimum mint amount:

    • Format: Numeric

    • Type: Balance

    • Setting Function: set_minimum_mint

    • Value: 100_000_000_000_000_000_000

    • Explanation: 100 MANTA

  4. Minimum redeem amount:

    • Format: Numeric

    • Type: Balance

    • Setting Function: set_minimum_redeem

    • Value: 80_000_000_000_000_000_000

    • Explanation: 80 MANTA

  5. Currency supporting rebond:

    • Format: Currency

    • Type: CurrencyId

    • Setting Function: add_support_rebond_token

    • Value: CurrencyId::Token(MANTA)

    • Explanation: This setting is not required if the currency does not support rebond operations for users.

  6. Initial TimeUnit for fast redemption processing:

    • Format: Currency

    • Type: CurrencyId

    • Setting Function: set_min_time_unit

    • Value: TimeUnit::Round(850)

    • Explanation: Set to the TimeUnit just before the first listing.

  7. Maximum number of user unlocking records that can be refunded at the beginning of each block:

    • Format: Numeric

    • Type: u32

    • Setting Function: set_hook_iteration_limit

    • Value: 10

  8. Maximum number of unlocking records that can exist for a user at the same time:

    • Format: Numeric

    • Type: u32

    • Setting Function: pallet constant MaximumUnlockIdOfUser

    • Value: 10

    • Explanation: Does not need to be set separately, written in the Runtime.

  9. Maximum number of unlocking records that can exist for each expiration era:

    • Format: Numeric

    • Type: u32

    • Setting Function: pallet constant MaximumUnlockIdOfTimeUnit

    • Value: 50

  10. Fee collection account for mint and redeem:

    • Format: FeeAccount Account

    • Type: AccountId

    • Setting Function: pallet constant

    • Value: Treasury

    • Explanation: Does not need to be set separately, written in the Runtime.

SLP module

The SLP module is responsible for communicating with the ParachainStaking module of the Manta chain by sending cross-chain messages to perform operations such as delegate, delegate_bond_more, schedule_delegator_bond_less, schedule_revoke_delegation, execute_delegation_request, cancel_delegation_request, schedule_leave_delegators, execute_leave_delegators, cancel_leave_delegators. The delegator account is generated by Bifrost's parachain address on the Manta chain, and the corresponding sub-account is generated by calling the as_derivative function of the utility module. All delegator and validator addresses are stored and used in the format of MultiLocation in the module.

Storages and Functions

  1. Backend service operates multi-signature accounts:

    • Format: Account

    • Type: AccountId

    • Setting Function: set_operate_origin

    • Value:

    • Explanation: Both MANTA and BNC need to be set.

  2. Supplementary account source for MANTA transaction fees, and the amount to be supplemented each time:

    • Format: Account, Amount

    • Type: MultiLocation, Balance

    • Setting Function: set_fee_source

    • Value: Treasury Account: MultiLocation { parents: 0, interior: X1(AccountId32 { network: NetworkId::Any, id: 0x6d6f646c62662f74727372790000000000000000000000000000000000000000 }) } MANTA Value: 100_000_000_000_000_000_000

    • Explanation: Treasury, 100 MANTA

  3. Supplementary account source for BNC transaction fees, and the amount to be supplemented each time: (already set)

    • Format: Account, Amount

    • Type: MultiLocation, Balance

    • Setting Function: set_fee_source

    • Value: Treasury Account: MultiLocation { parents: 0, interior: X1(AccountId32 { network: NetworkId::Any, id: 0x6d6f646c62662f74727372790000000000000000000000000000000000000000 }) } BNC Value: 1_000_000_000_000

    • Explanation: Treasury, 1 BNC

  4. Minimum bonded amount reserved for Delegator qualification:

    • Field: delegator_bonded_minimum

    • Type: Balance

    • Setting Function: set_minimums_and_maximums

    • Value: 500_000_000_000_000_000_000

    • Explanation: 500 MANTA

  5. Minimum amount for each bond_extra operation by Delegator:

    • Field: bond_extra_minimum

    • Type: Balance

    • Setting Function: set_minimums_and_maximums

    • Value: 100_000_000_000_000_000_000

    • Explanation: There is no limit on the MANTA network, but we set it to 100 MANTA.

  6. Minimum amount for each unbond operation by Delegator:

    • Field: unbond_minimum

    • Type: Balance

    • Setting Function: set_minimums_and_maximums

    • Value: 100_000_000_000_000_000_000

    • Explanation: There is no limit on the MANTA network, but we set it to 100 MANTA.

  7. Minimum amount for each rebond operation by Delegator:

    • Field: rebond_minimum

    • Type: Balance

    • Setting Function: set_minimums_and_maximums

    • Value: 1_000_000_000_000_000_000

    • Explanation: This is for the entire request rebond, so there is no limit. Set to 1 MANTA.

  8. Maximum number of unlocking entries that can exist for each Delegator at the same time:

    • Field: unbond_record_maximum

    • Type: U32

    • Setting Function: set_minimums_and_maximums

    • Value: 32

    • Explanation: Not applicable to MANTA; MANTA has no limit.

  9. Maximum number of Validators that each Delegator can operate at the same time:

    • Field: validators_back_maximum

    • Type: U32

    • Setting Function: set_minimums_and_maximums

    • Value: 25

  10. Soft cap for each Delegator's staking funds that can be operated at the same time:

    • Field: delegator_active_staking_maximum

    • Type: Balance

    • Setting Function: set_minimums_and_maximums

    • Value: 2_000_000_000_000_000_000_000_000

    • Explanation: 2 million MANTA

  11. Maximum number of delegators that each Validator can reward:

    • Field: validators_reward_maximum

    • Type: u32

    • Setting Function: set_minimums_and_maximums

    • Value: 100

    • Explanation: The top 100 delegators in topDelegation can receive staking rewards.

  12. Minimum binding amount between each Validator and Delegator relationship:

    • Field: delegation_amount_minimum

    • Type: Balance

    • Setting Function: set_minimums_and_maximums

    • Value: 50_000_000_000_000_000_000

    • Explanation: 500 MANTA

  13. Maximum number of delegators that can be created:

    • Field: delegators_maximum

    • Type: u16

    • Setting Function: set_minimums_and_maximums

    • Value: 100

  14. Maximum number of validators that can be added to the pool:

    • Field: validators_maximum

    • Type: u16

    • Setting Function: set_minimums_and_maximums

    • Value: 500

  15. Waiting time between Delegator Unlock and the available amount for withdrawal:

    • Field: validators_maximum

    • Type: TimeUnit::Round(x)

    • Setting Function: set_currency_delays

    • Value: 28

  16. Waiting time between applying to leave Delegator qualification and the available amount for withdrawal:

    • Field: leave_delegators_delay

    • Type: TimeUnit::Round(x)

    • Setting Function: set_currency_delays

    • Value: 28

  17. Hosting fee rate and receiving account:

    • Field: Hosting fee rate, Receiving account

    • Type: Permill, MultiLocation

    • Setting Function: set_hosting_fees

    • Value: Treasury Account: MultiLocation { parents: 0, interior: X1(AccountId32 { network: NetworkId::Any, id: 0x6d6f646c62662f74727372790000000000000000000000000000000000000000 }) } Rate: 1000

    • Explanation: 0.1%, as it is per mil, so enter as 1000; Treasury

  18. Limitations on exchange rate adjustments:

    • Field: Maximum number of operations per TimeUnit for each CurrencyId, and the percentage of the total MANTA pool amount that can be operated each time

    • Type: u32, Permill

    • Setting Function: set_currency_tune_exchange_rate_limit

    • Value: 1, 1000

  19. Restriction on ongoingTimeUnit update for each CurrencyId:

  • Field: The minimum number of blocks in Bifrost before each CurrencyId can adjust ongoingTimeUnit

  • Type: BlockNumber

  • Setting Function: set_ongoing_time_unit_update_interval

  • Value: 600

  • Explanation: Manta's round is 6 hours. Bifrost parallel chain produces a block every 12 seconds. Theoretically, 1800 blocks equal one round in Manta. With a buffer of 3 times, at least 600 blocks can be updated once.

  1. Maximum number of xcm-related storage updates at the beginning of each block:

  • Field: MaxTypeEntryPerBlock

  • Type: u32

  • Setting Function: Constant set in Runtime

  • Value: 10

  1. Maximum number of expired user refunds to be processed in each block:

  • Field: MaxRefundPerBlock

  • Type: u32

  • Setting Function: Constant set in Runtime

  • Value: 10

  1. Supplement Fee Account Whitelist

  • Field: SupplementFeeAccountWhitelist

  • Type: MultiLocation

  • Setting Function: add_supplement_fee_account_to_whitelist

  • Value:

  • Explanation: Accounts other than delegator accounts and operateOrigin accounts that need to supplement fees. Generally, this includes multi-signature accounts and their signatories.

  1. Validator Whitelist

  • Field: Validator accounts available for Delegator staking

  • Type: MultiLocation

  • Setting Function: add_validator

  • Value:

  1. Weight and fees for cross-chain operations:

  • Field: Weight and fee amount for each cross-chain operation

  • Type: Weight, Balance

  • Setting Function: set_xcm_dest_weight_and_fee

  • Value:

PreviousvGLMR & vMOVRNextvASTR

Last updated