PROJECTDCA SECURITY

Built for transparency. Designed for user control.

ProjectDCA uses encrypted wallet storage, protected environment variables, verified Stripe webhooks and public blockchain execution. Security also depends on responsible user behaviour, careful strategy settings and safe handling of wallet credentials.

Encrypted wallets

Stored wallet private keys are encrypted before being saved in the database.

On-chain activity

Base transactions remain publicly visible and independently verifiable.

Stripe payments

Card details are processed by Stripe rather than stored by ProjectDCA.

User controls

Users choose wallet limits, buy sizes, intervals and when a bot starts or stops.

WALLET PROTECTION

Encrypted wallet credentials

ProjectDCA can create or import blockchain wallets for use with automated DCA strategies. Where private keys are stored by the service, they are encrypted before being written to the database.

The application uses a dedicated wallet-encryption secret supplied through protected server environment variables. Each encrypted entry includes a unique initialization value so identical private keys do not produce identical stored records.

  • Private keys are not intended to be stored in readable plaintext inside the database.
  • Wallet credentials are decrypted only when required to create a wallet signer and execute a requested transaction.
  • A newly created wallet’s private key is displayed to the user so it can be recorded securely.
  • ProjectDCA does not ask users to post private keys or seed phrases in the Telegram community.
Important: ProjectDCA wallets should not be used as your primary wallet or long-term crypto storage. Only fund them with the amount needed for your selected strategy.
INFRASTRUCTURE

Protected application configuration

Sensitive application configuration is intended to remain in Railway environment variables rather than being written directly into public website files.

Environment variables

Bot tokens, RPC credentials, Stripe secrets, database connection details and wallet-encryption keys are loaded server-side.

Private source repository

The ProjectDCA application repository can remain private while the public website is delivered through the running Railway service.

HTTPS website delivery

The Railway public domain serves the website over HTTPS, protecting data in transit between visitors and the site.

Database separation

User settings, encrypted wallet records and subscription status are stored in PostgreSQL rather than exposed in public website files.

Railway restarts and deployments are handled with shutdown logic intended to stop active timers and the Telegram bot cleanly before the application process exits.

PAYMENT SECURITY

Stripe and on-chain payment verification

Stripe subscriptions

Stripe hosts the subscription checkout and processes supported card payment information. ProjectDCA does not need to store full card numbers or security codes.

Stripe webhook requests are checked using the webhook signing secret before ProjectDCA accepts an event as authentic.

  • Completed checkout sessions carry the Telegram user ID and plan name required to activate the correct account.
  • Subscription cancellation or pause events can move the account back to the Free plan.
  • Live Stripe API keys and the webhook signing secret remain server-side.

Cryptocurrency payments

ETH and USDC payments are confirmed using public transaction data on Base. Payment requests use an exact requested amount so the service can match a confirmed transfer to the pending Telegram account.

Crypto payment access is time-limited and tracked separately from recurring Stripe subscriptions.

BLOCKCHAIN TRANSPARENCY

Publicly verifiable execution

DCA purchases and wallet funding transactions occur on Base. Blockchain transactions can be independently reviewed through a public block explorer using the wallet address or transaction hash.

  • Wallet addresses are visible on-chain.
  • Transaction amounts and gas usage are publicly recorded.
  • Token transfers can be reviewed through Base block explorers.
  • Users can independently confirm whether a transaction succeeded.
Blockchain transparency does not guarantee that a token, pool, smart contract or liquidity source is safe. Users must verify the token address and pool before starting a strategy.
USER CONTROLS

Control over strategy limits

ProjectDCA is designed to let users determine how their strategy operates rather than automatically choosing investment decisions for them.

βœ“

Configurable purchase sizes

Users select minimum and maximum ETH amounts for recurring purchases.

βœ“

Adjustable execution intervals

Users choose how many seconds pass between DCA attempts.

βœ“

Active-wallet limits

Each bot can be limited to the first selected number of wallets within the user’s plan.

βœ“

Start and stop controls

A running DCA bot can be stopped through Telegram whenever the user chooses.

βœ“

Withdrawal address

Users can configure the destination address used when withdrawing supported funds.

LIMITATIONS

No platform is risk-free

Encryption and access controls reduce certain risks, but they do not eliminate all possible failures. ProjectDCA depends on several external systems that may experience outages, vulnerabilities or unexpected behaviour.

  • Telegram availability and account security.
  • Railway hosting and database availability.
  • RPC-provider accuracy, uptime and rate limits.
  • Base network performance and transaction finality.
  • Uniswap contracts, pools and liquidity.
  • Third-party ERC-20 token contracts.
  • User device and browser security.

ProjectDCA has not been presented as independently audited. Users should not assume that the service, its wallet handling or its transaction logic has received a formal third-party security audit unless that is explicitly announced in the future.

Never deposit more than you can afford to lose. Smart-contract failures, market losses, incorrect settings and compromised credentials can result in permanent loss of funds.
USER BEST PRACTICES

How users can reduce risk

  • Start with a small amount and confirm the strategy works as expected.
  • Verify the token contract address and pool ID before starting DCA.
  • Use ProjectDCA wallets only for automation, not for primary savings.
  • Store any displayed private key offline in a secure location.
  • Never share a seed phrase or private key with support members, administrators or community users.
  • Protect the Telegram account with a strong password and Telegram two-step verification.
  • Review active bots, wallet balances and recent transactions regularly.
  • Stop the bot immediately if transactions or balances appear unexpected.
  • Confirm the withdrawal address carefully before moving funds.
  • Avoid following token addresses or support instructions sent by unknown private accounts.
CONTINUED DEVELOPMENT

Planned security improvements

ProjectDCA is under active development. Potential future security and account-management improvements may include:

β†’

Expanded activity logs

Better visibility into important account, wallet and bot actions.

β†’

Account alerts

Additional notifications for subscription, wallet or strategy events.

β†’

Web dashboard controls

A dedicated interface for viewing bot status and selected settings.

β†’

Independent review

Formal code review or security auditing as the platform and user base grow.

Planned items are not guarantees and may change based on development priorities and technical requirements.

SECURITY CONTACT

Report suspicious activity

Report suspected security issues, unauthorized account activity or suspicious ProjectDCA impersonators through the official Telegram community.

Do not include private keys, seed phrases, complete payment information or other secrets in a public support message.

Official ProjectDCA Support

Use the official community link and be cautious of unsolicited direct messages claiming to represent ProjectDCA.

Open Telegram Support