Skip to main content

Risk Assessment

Landscape​

In the context of blockchain technology, applications do not interact with the blockchain directly. Instead, they use public nodes or secondary nodes—often referred to as cache nodes—to retrieve the latest state of the blockchain.

Take, for example, the process of executing a transfer on the Ethereum Virtual Machine (EVM) network. To accomplish this, one needs to obtain several pieces of information, including the number of transactions (transaction count), as well as the applicable gas and gas price. The transaction count is readily available from the nodes, while the other necessary data is provided by information aggregation services. These services analyze average transaction costs and estimate the forthcoming cost that will allow a transaction to be confirmed on the network within a given timeframe.

This approach is similarly applicable to Decentralized Exchange (DEX) swaps. Successful transactions are conducted by sourcing real-time data on the current state of the blockchain and determining the most cost-effective route to ensure the transaction is secured.

These operations are facilitated by additional information services that deploy algorithms to compute the various transaction parameters. However, initiating a transaction ultimately falls to the client. Using a private key, the client signs off on the transaction, thereby authorizing it.

Interacting with the blockchain can thus be broken down into three distinct components:

  1. The Blockchain itself, which serves as the immutable ledger of truth.
  2. Information Services that perform computations and provide data in a format that is easily understood, enabling real-time decision-making for users.
  3. Custodial Services that interface with the blockchain through these information services and ultimately handle the submission of transactions to the blockchain.

Some examples of blockchain systems include:

  • Ethereum
  • Binance Smart Chain
  • Solana
  • TRON
  • Polkadot

Information services comprise:

Importantly, none of these platforms retain the private keys of their clients.

Custodial solutions that can be constructed using these informational services include:

  • Centralized Exchanges, which amalgamate data from a variety of information sources and node providers, and also manage the storage of private keys.
  • Centralized Telegram Bots, which possess an internal custodial backend that interfaces with multiple services to gather information. The power to make transaction decisions, though, is delegated to the individual users of the bot.
  • Payment platforms and all entities that involve the storage and management of private keys.

Commitment​

Within our platform, all monetary assets are directed to specific contract addresses.

The initial setup of contract factories is executed once on our back-end service, enabling their use across numerous wallets. These factories are not governed by any central ownership.

The factory is designed to facilitate the deployment of smart wallets, a process only the client can initiate using their private keys. Subsequently, clients retain the ability to retrieve their assets even in the event our back-end services become inoperative.

Should a client misplace their private key, our back-end does not have the capability to access or withdraw the client's funds, as access is exclusively tied to the client's private key.

Our service is structured such that it never assumes a custodial role over the client's funds.

Consequently, this ensures that third parties external to our organization are barred from accessing the assets.

Possible Risks and Solution​

Risk: Feemaker can send false information about deposit, in fact that deposit was not happened.

Solution: Client's backend can verify the event in trusted source by transaction id to make the decision that event is happened

Risk: Feemaker can be shut down.

Solution: Thats means client's backend will not receive the information about deposit at all but in fact deposit could be happended. In this case the business maybe paused but not destroyed. Because there is a still possibility to recalculate the state inside the blockchain and make the transaction directly in smart contract.

Risk: Feemaker can send false information for withdraw request. As far feemaker has internal coin selection alogorithm, it can possiblity cheat with that when you request withdraw 123 coins on XYZ address you receive payload to withdraw 125 coins on DDD address.

Solution: It can be simply verified by client's backend. Once you send the request to inti withdraw you provide the amount and recepient. Once you receive the payload clinet's backend can verify to field and payload that it matches to the initial request. It can be done by any transaction data decoder with ABI of the contract.