Integrating with Multisig Accounts
In order to make it easily and quickly for other Cosmos Eco projects without integrated ICA features to get their own liquid staking derivatives, StaFiHub has developed a Liquid Staking SDK and identified a complete integration process.
In general, integrating a new rToken does not require any development, mainly to run the rToken relay service.
The whole program is divided into three parts:
StaFiHub chain
Based on cosmos-sdk, the on-chain module implements rToken-related functions, such as mint rToken, unbond function for user, exchange rate update, etc. In addition, there are some modules for rToken application scenarios, such as rDEX.
When integrating a new rToken, the StaFiHub chain does not require additional development, only need to register the relevant information of the new rToken.
rToken relay service
It mainly deals with cross-chain related logic (similar to the functions as a cross-chain bridge). Multiple relay nodes jointly manage multi-signature accounts and initiate related multi-signature transactions, such as delegate, undelegate, and withdrawDelegationReward on the target chain, and also need to interact with the StaFiHub chain.
StaFiHub App
The front-end interactive DApp, on which users can stake the target chain token, unbond the token, participate in DEX transactions, etc. StaFiHub holds the app that integrates all rTokens, and you can easily add a new chain configuration to integrate a new rToken.
The above rToken relay service and the DApp are also openly designed, and the access party can also do some customized logic and design based on this, or run the DApp independently, etc.
Here are the detail steps about the entire integration process of the SDK.
Steps
Step 1
Contact StaFiHub, please join in the Discord and contact the @CoreDev to talk about the integration.
Then, we need to confirm the following access parameters, which will eventually be registered on the StaFiHub chain:
| Flags | Description | Example |
|---|---|---|
denom | The denomination used by the target chain. | uatom |
decimals | Decimal points to covert minimal denomination to user-facing denomination | 6 |
bech32PrefixAccAddr | Prefix of account address. | cosmos |
bech32PrefixValAddr | Prefix of validator address. | cosmosvaloper |
pool(multi-signature account) | The multi-signature account. Generally co-generated with StaFiHub and others. | cosmos12yprrdprzat35zhqxe2fcnn3u26gwlt6xcq0pj |
poolSubAccounts | Sub accounts(relay accounts) of the multi-signature account(pool). Each rToken realy service needs to import an account to initiate transactions with the target chain(like Cosmos). 7 accounts recommended on mainnet. | cosmos1lyqrtft9x286gfsf30rf8vtvmc3jgd0mevd8p3:cosmos1u5dfrwye0vgtf706wc0h55vl06v0mc23fsu225:cosmos1pv9vxz6d38thesq82dgfuhdlujj0vwkddkpkvp |
poolSubAccountPubkeys | Pubkeys of sub accounts(relay accounts). Each rToken realy service needs to import other pubkeys to generate the multi-signature account locally. | '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"Apd6n7lU/YOEvsHPvETl6p+joYtddcKenjGmceAp7trz"}' |
poolThreshold | Threshold of the multi-signature account(pool). 4 recommended on mainnet. | 2 |
stafiRelayers | Relay accounts of StaFiHub. Each rToken realy service needs to import an account to initiate transactions with the StaFiHub. 7 accounts recommended on mainnet. | stafi17yl0s0zh7u87uhluzn2egg5ru2hy3jqxfspdlp:stafi12a0n3294pncp24c93d0as3g3t5zjhcnrnugsd7:stafi1tjg6cw5lklvz7nwd0ck9veua9ldm4lxnrr99y4 |
stafiRelayerThreshold | Threshold of the relayers. 4 recommended on mainnet. | 2 |
gasPrice | Gas price. Ensure that each rToken realy service can successfully initiate a transaction to the target chain. | 0.025uatom |
bondingDuration | Unbonding time of the target chain. | 21days |
leastBond | Minimum staking amount to mint rToken(Optional). Usually decided by StaFiHub. | 0.1ATOM |
The most important of these parameters is the pool account, which is a multi-signature account used to manage token assets(like ATOM) of the target chain and initiate transactions such as staking and transfer on the target chain. So we need to ensure the security of the multi-signature account to prevent risks such as asset loss.
StaFi foundation strongly recommends decentralizing the key-holder of sub-accounts due to the risk. At the early stage, the decentralization transition can be initiated from the foundation, known community members, trusty third parties to the governance, we would recommend that StaFi Foundation hold 3 sub-accounts and the foundation of the target chain needs to hold 4 sub-accounts. Target chain foundation can choose trustworthy community members to hold some sub-accounts, but at present we recommend that the community should hold no more than 2 sub-accounts. And we will open more in the future if necessary.
Risk: As we know, once a multi-signature account is generated, it cannot be changed, and sub-accounts cannot be replaced either. So all members must be stable and trustworthy. If some sub-accounts are permanently lost, we need to migrate the assets on the multi-signature account in time.
Step 2
One of the relay service's tasks is to invoke staking related calls based on the multi-signature pool accounts on the target chain. Multiple relay services work together to manager these pool accounts which are secure only if as many parties as possible are running the relay service.
Check the staking mechanism of the target chain. Current code of relay service is perfectly aligned with the current staking module of the Cosmos-SDK, however, if the target chain does not adopt staking Module of the Cosmos-SDK, instead, a self-built staking module is used, then the SDK for the target chain on which relay service depends needs to be rebuild to fit that module.
Prepare RPC endpoints. A relay service connects both StaFiHub and the target chain, so RPC endpoints of both two chains are needed to provide. In addition, to ensure that a relay service will not break down due to the disconnection of an RPC endpoint, it is best to configure multiple RPC endpoints. We suggest that the target chain run the nodes themselves, or cooperate with other validators and node service providers in the network.
Prepare the configuration file for the relay service like this.
Install Go.
Use the key tool to build keys for the relay service.
Run relay service. You can refer to the README.md file under the project.
Note:If you hold multiple sub-accounts, you also need to run multiple rToken relay services.
Example
(1) Install go
(2) build
(3) Generate key
Note: To ensure security, we strongly recommend generating these keys offline and backing up the mnemonic phrases and the passwords, and then migrating the keyring-file to the server running the rToken relay service.
In addition, if you hold for example 3 sub-accounts, you need to generate multiple keys, such as stafihub-relay-1, stafihub-relay-2, stafihub-relay-3 and cosmos-relay-1, cosmos-relay-2, cosmos-relay-3. But please remember that each keyring-file only contains the private key information of one sub account to prevent the loss of multiple sub-accounts at one time.
key example:
(4) Generate multi-signature account(pool)
Note: Each rToken relay service needs to import pubkeys of all other relay accounts(sub accounts), and then generate the multi-signature account locally. Because each rToken relay service needs to configure the multi-signature account in the local configuration file.
(5) Prepare config.json
startBlock: When starting the rToken relay for the first time, startBlock needs to be configured as the current block of the network. Under normal circumstances, the startBlock does not need to be modified during subsequent restarts (the latest block of the chain will be recorded in the blockstore when the relay service running).
blockstorePath/keystorePath/account: Please replace with your own configuration.
endpointList: Chain RPC list. It is strongly recommended to configure at least two RPCs to ensure the stability of the rToken service.
multisig1: The multi-signature account name, please replace with your own configuration.
(6) Run
Use the following command to run the service in the background. Maybe you can create a systemd service or use some commands like screen or nohup, or some other tools.
Step 3
Please follow this.
Last updated