---
tags: WPOKT, POKT, Pocket, Proposal
title: ⚔️ Raid Guild Proposal <> wPOKT ⚔️
---
# WPOKT BackEnd Scoping Document (updated)
Develop a system that can facilitate the minting of wPOKT tokens upon receiving POKT tokens on the Pocket network to a designated address. The system should also enable the return of POKT tokens upon burning wPOKT tokens on the Ethereum Mainnet.
## Stack
- Golang - validator nodes
- Mongodb Database
## Architecture
- The "wPOKT validator node" will be responsible for the bridging process. More details in Specs
- To ensure security, the wPOKT Nodes will be deployed on a Virtual Private Cloud (VPC) on AWS/GCP with limited network connectivity. Specifically, they will not have any incoming network connections to minimize the overall attack surface.
- We can further enhance this distribution by deploying each node on varied AWS regions, which can help to minimize the risk of data center failures by spreading the nodes across multiple geographic locations.
- Mints on Eth network will be signed by M/N (9/12) validators and this transaction will be executed by the user who will also pay the gas required
- Burns / Invalid Mints on Pokt network will be signed by N/N multisig of validators and submitted to the network. The user shall received the amount minus the gas fees.
- To ensure security of keys they will be managed by a Key Management Service (KMS) on AWS/GCP and deployed to the signer nodes securely.
## Specs
- Each wPOKT node will have the following active threads:
1. Monitor POKT transfers txs + create mint entry / invalid_mint entry
2. Sign mint txs on ETH network
3. Monitor mints on ETH network
4. Monitor burn transactions + create burn entry
5. Sign return txs for burns / invalid_mints on POKT network
6. Submit return txs on POKT network and wait for confirmation
- The first two threads together manage the mint flow whereas the last three threads manage the burn flow.
- Invalid mints are returned in thread 5 as well.
- Each node has a local state of latest block scanned for both pocket and ethereum networks.
### Mint Flow
#### I. Monitor POKT transfers txs + create mint entry / invalid_mint entry - 16hrs
- It will actively monitor POKT transactions on the Pocket network that contain a specific memo and a transfer to our Multisig vault on Pokt network.
- Monitoring will start from the last block scanned as per local state, starting from a "startBlock" until the latest block.
- Upon noticing such transactions it creates a mint entry in the database:
```
status "pending" | "confirmed" | "signed" | "submitted" | "success" | "failed"
type Mint struct {
Id *primitive.ObjectID `bson:"_id,omitempty"`
TransactionHash string `bson:"transaction_hash"`
Height string `bson:"height"`
SenderAddress string `bson:"sender_address"`
SenderChainId string `bson:"sender_chain_id"`
RecipientAddress string `bson:"recipient_address"`
RecipientChainId string `bson:"recipient_chain_id"`
Amount string `bson:"amount"`
CreatedAt time.Time `bson:"created_at"`
UpdatedAt time.Time `bson:"updated_at"`
Status string `bson:"status"`
TypedData string `bson:"typed_data"`
Signers []string `bson:"signers"`
Signatures []string `bson:"signatures"`
}
```
- If the Memo is invalid then an invalid_mint entry is added to the database:
```
type InvalidMint struct {
Id *primitive.ObjectID `bson:"_id,omitempty"`
TransactionHash string `bson:"transaction_hash"`
Height string `bson:"height"`
SenderAddress string `bson:"sender_address"`
SenderChainId string `bson:"sender_chain_id"`
Amount string `bson:"amount"`
CreatedAt time.Time `bson:"created_at"`
UpdatedAt time.Time `bson:"updated_at"`
Status string `bson:"status"`
ReturnTx string `bson:"return_tx"`
Signers []string `bson:"signers"`
ReturnTxHash string `bson:"return_tx_hash"`
}
```
- Entry can be created by any of the 12 watcher nodes. We shall ensure that only one of them is successful in creating this by having an index in the database to ensure only one entry is created per transaction hash from a particular user and a particular amount.
#### II. Sign mint txs on ETH network w/ unit tests - 16 hrs
- It will be monitoring the database for new mint entries. Upon finding such entries it shall act based on the status of the entry:
- `pending`
- check block confirmations and update the db with the number of confirmations, if it is greater than a stipulated value then update the status to `confirmed`
- `confirmed`
- check if there's already signatures / a return tx
- if there is already mint tx data then sign it and add public key to the list of signers
- if there is no mint tx data then build and sign it and add public key to the list of signers
- update mint entry with the latest tx and signatures
- if we have enough signatures then mark it as signed
#### III. Monitor mints on ETH network w/ unit tests - 4 hrs
- Monitor the WPOKT contract on Ethereum network for new mints
- Co-relate each mint to the corresponding mint entry in the database and mark it as "success"
### Burn flow
#### IV. Monitor burn transactions + create burn entry w/ unit tests - 8 hrs
- It will actively monitor actively monitor wPOKT burn transactions on the Ethereum network.
- Monitoring will start from the last block scanned as per local state, starting from a "startBlock" until the latest block.
- Upon noticing such transactions it creates a burn entry in the database:
```
type Burn struct {
Id *primitive.ObjectID `bson:"_id,omitempty"`
TransactionHash string `bson:"transaction_hash"`
LogIndex string `bson:"log_index"`
BlockNumber string `bson:"block_number"`
SenderAddress string `bson:"sender_address"`
SenderChainId string `bson:"sender_chain_id"`
RecipientAddress string `bson:"recipient_address"`
RecipientChainId string `bson:"recipient_chain_id"`
Amount string `bson:"amount"`
CreatedAt time.Time `bson:"created_at"`
UpdatedAt time.Time `bson:"updated_at"`
Status string `bson:"status"`
ReturnTx string `bson:"return_tx"`
Signers []string `bson:"signers"`
ReturnTxHash string `bson:"return_tx_hash"`
}
```
- Entry can be created by any of the 12 watcher nodes. We shall ensure that only one of them is successful in creating this by having an index in the database to ensure only one entry is created per transaction hash from a particular user and a particular amount.
#### V. Sign return txs for burns / invalid_mints on POKT network w/ unit tests - 8 hrs
- It will be monitoring the database for new burn / invalid_mint entries. Upon finding such entries it shall act based on the status of the entry:
- `pending`
- check block confirmations and update the db with the number of confirmations, if it is greater than a stipulated value then update the status to `confirmed`
- `confirmed`
- check if there's already signatures / a return tx
- if there is already return tx data then sign it and add public key to the list of signers
- if there is no return tx data then build and sign it and add public key to the list of signers
- update burn / invalid_mint entry with the latest tx and signatures
- if we have enough signatures then mark it as signed
#### VI. Submit return txs on POKT network and wait for confirmation w/ unit tests - 8 hrs
- It will be monitoring the database for 'signed' | 'submitted' burn / invalid_mint entries. Upon finding such entries it shall act based on the status of the entry:
- `signed`
- submit transaction and mark as "submitted"
- `submitted`
- check if tx is confirmed and mark as "success" | "failed"
### Testing & Deployment - 10 hrs
- End to end testing
- User testing
- Testnet & mainnet deployment
## Considerations
- To display the status of user transactions, the frontend using nextJS API should have read-only credentials to access the MongoDB database.
- The structure of the mint, invalid_mint and burn entries may undergo changes as necessary during the development process.
Sign in with Wallet
Connect another wallet