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
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;
MANTA Ready Pool matches Mint amount and Redeem amount;
Oracle monitor matching results from MANTA Ready Pool and send messages to Manta-Bifrost SLP addresses;
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
Users initiate a vMANTA redeem orders to MANTA Ready Pool;
MANTA Ready Pool matches Redeem amount and Mint amount, and dispatches the remaining MANTA to vMANTA redeem orders, SLP destroys the redeemed vMANTA amount;
Oracle monitor redeem orders from Bifrost chain and send messages to Manta-Bifrost SLP addresses;
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.
💡 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
Update round numbers
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.
Withdrawal of redemption due amount
Repay the current due debt and transfer the remaining amount to the entry account for quick redemption.
Query and compensate the reserve amount of handling fees for each operating account.
Before Round ends
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.
Check the ledger, warn and adjust accordingly if there are discrepancies.
Attention for staking operations:
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.
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%.
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
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.
Time to wait after user redemption:
Format: Round
Type: TimeUnit::Round(x)
Setting Function: set_unlock_duration
Value: 28
Minimum mint amount:
Format: Numeric
Type: Balance
Setting Function: set_minimum_mint
Value: 100_000_000_000_000_000_000
Explanation: 100 MANTA
Minimum redeem amount:
Format: Numeric
Type: Balance
Setting Function: set_minimum_redeem
Value: 80_000_000_000_000_000_000
Explanation: 80 MANTA
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.
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.
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
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.
Maximum number of unlocking records that can exist for each expiration era:
Format: Numeric
Type: u32
Setting Function: pallet constant MaximumUnlockIdOfTimeUnit
Value: 50
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
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.
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
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
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
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.
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.
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.
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.
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
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
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.
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
Maximum number of delegators that can be created:
Field: delegators_maximum
Type: u16
Setting Function: set_minimums_and_maximums
Value: 100
Maximum number of validators that can be added to the pool:
Field: validators_maximum
Type: u16
Setting Function: set_minimums_and_maximums
Value: 500
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
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
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
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
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.
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
Maximum number of expired user refunds to be processed in each block:
Field: MaxRefundPerBlock
Type: u32
Setting Function: Constant set in Runtime
Value: 10
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.
Validator Whitelist
Field: Validator accounts available for Delegator staking
Type: MultiLocation
Setting Function: add_validator
Value:
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:
Last updated
