Risk Assessment
Why This Page Exists
Centralized payment services maintain a long list of security assumptions they cannot publicly disclose — doing so would expose their attack surface. Users must trust that the provider handles custody, key management, fraud detection, and internal access controls correctly, with no way to independently verify any of it.
Feemaker takes the opposite approach. Because our architecture is non-custodial, our risk surface is small and fully transparent. We can list every theoretical risk and its mitigation here, because none of them give an attacker access to your funds. This level of transparency is only possible when the service never holds your keys.
Architecture Overview
Blockchain applications don't interact with the chain directly. They rely on three layers:
- The Blockchain — the immutable source of truth (Ethereum, BSC, Polygon, TRON, etc.)
- Information Services — compute data like gas prices, optimal swap routes, balances, and transaction notifications. They never hold private keys.
- Custodial Services — platforms that combine information services with key storage to submit transactions on behalf of users.
Feemaker is an information service, not a custodial service. We compute payment addresses, provide deposit notifications, and prepare transaction payloads — but we never store, access, or manage your private keys.
Examples of information services (none hold private keys):
| Service | Purpose |
|---|---|
| Infura | Node access |
| Gas Tracker | Gas price estimation |
| 1inch API | Optimal swap routes |
| Feemaker | Non-custodial smart wallet infrastructure |
| Electrum | Balance and transaction notifications |
Custodial services (they hold private keys — larger risk surface):
- Centralized Exchanges
- Custodial Telegram Bots
- Payment platforms with internal key management
Our Commitment
- All funds are directed to contract addresses controlled by the client's private key.
- Contract factories are deployed once and are not governed by any central ownership.
- Only the client can deploy smart wallets and withdraw funds using their private key.
- If our backend goes offline, clients retain full access to their funds on-chain.
- If a client loses their private key, we cannot recover or access their funds — by design.
- We never assume a custodial role. Third parties, including us, cannot access client assets.
Theoretical Risks
Because Feemaker is non-custodial, our entire risk surface fits in the table below. A centralized service could never publish an equivalent list — their attack surface is orders of magnitude larger and disclosure would compromise their security.
Risk 1: False Deposit Notification
Scenario: Feemaker reports a deposit that never actually occurred on-chain.
Mitigation: Your backend can verify every event independently by checking the txid against a trusted blockchain source (e.g. your own node, Etherscan, Infura). Never trust a notification alone — always confirm on-chain.
Impact if exploited: None, if verification is implemented. The blockchain is the source of truth.
Risk 2: Service Downtime
Scenario: Feemaker goes offline and stops sending deposit notifications.
Mitigation: Deposits still happen on-chain regardless of our status. Your business may pause, but no funds are lost. You can recalculate state directly from the blockchain and interact with the smart contracts without our service.
Impact if exploited: Temporary business interruption. Zero fund loss.
Risk 3: Tampered Withdrawal Payload
Scenario: When you request a withdrawal of 123 coins to address 0xABC, Feemaker returns a payload that actually sends 125 coins to address 0xDDD.
Mitigation: Your backend should verify the returned payload before signing. Decode the transaction data using the contract ABI and confirm that the to field and amount match your original request. Never blindly sign a payload.
Impact if exploited: None, if verification is implemented. You control the signing step.
Summary
| Risk | Can attacker steal funds? | Requires your action? |
|---|---|---|
| False deposit notification | No | Verify txid on-chain |
| Service downtime | No | Read state from blockchain |
| Tampered withdrawal payload | No | Verify payload before signing |
In all cases, the client retains full control. Every risk has a client-side verification step that eliminates the threat entirely. This is the fundamental advantage of non-custodial architecture — trust is replaced by verification.