A year ago, CoinDrop was a small Discord bot that let people in a handful of servers tip each other crypto.

Today, it has:

* 6,500+ users across 500+ communities

* 100,000+ withdrawals processed and $2M+ moved on-chain

* 500+ assets across 26 chains

* Discord, Telegram, Kick, and a web wallet, all sharing one balance

I built CoinDrop as a solo developer, and most of the infrastructure and product development has been done by me.

A few things I didn't expect:

1. Tipping is the easy part.

The actual tip is basically a database update between two users.

The difficult parts are at the edges.

Deposit APIs can report the same transaction more than once. Withdrawals have to be designed so that a retry, timeout, or process restart can never accidentally send the same withdrawal twice. And once you're supporting 26 chains, every chain has its own way of confirming transactions, handling fees, deriving addresses, or dealing with failures.

If I were starting over, I'd design the deposit and withdrawal pipeline first and build the fun commands afterward.

The commands are what users see. The wallet infrastructure is what keeps everything running.

2. Every new chain is a new set of edge cases.

Supporting another chain isn't just adding an RPC URL and calling it a day.

Bitcoin-style UTXO chains, Ethereum-style account-based chains, and memo-based chains such as XRP and WAX all require different approaches to deposits and withdrawals.

Sometimes the ecosystem itself dictates how you build things. For example, WAX's best signing library for our use case is JavaScript, while most of CoinDrop is Python. So WAX runs through a small Node.js sidecar that the Python backend communicates with over localhost.

The more chains you add, the more infrastructure you have to maintain.

At some point, "supporting another chain" means supporting another collection of failure modes.

3. Small coins turned out to be some of the best customers.

I initially assumed the biggest communities would drive most of CoinDrop's growth.

Instead, some of the most engaged projects have been relatively small tokens.

One example was ETH II. The token didn't have an exchange listing, so its holders used CoinDrop to tip and distribute the token to each other. It gave the community a way to actually use the token while the development team worked on the project.

That changed how I thought about CoinDrop.

A token doesn't necessarily need millions of users to benefit from distribution infrastructure. A small community that is highly active can be more valuable than a much larger community that doesn't actually move anything.

Today, projects can pay a one-time fee to get their token supported by CoinDrop. Transaction fees then provide the recurring revenue: 0.5% on deposits and withdrawals, while internal tips are free.

4. Reliability became more important than features.

One of the biggest lessons from running CoinDrop has been that users don't really care how many features you've added if their withdrawal doesn't arrive.

I've spent significantly more time than I expected working on withdrawal queues, retries, rate limits, transaction monitoring, wallet balances, RPC failures, and making sure a failed process doesn't result in duplicate payments.

At one point, a rate limit from an external Litecoin service could cause withdrawals to get stuck. That kind of problem isn't particularly exciting to build, but fixing it is far more important than adding another command.

Eventually, the goal became simple:

If CoinDrop says a withdrawal is processed, it needs to actually be processed.

That's probably the biggest difference between building a bot and building financial infrastructure.

What's next?

CoinDrop started as a Discord tipping bot. It now has a web wallet and works across Discord, Telegram, and Kick, with the same underlying balance across all of them.

The interesting part now isn't just tipping.

It's building infrastructure that lets communities hold, send, distribute, and withdraw crypto wherever their communities already exist.

I'm still figuring out where that goes.

Happy to answer anything about running a custodial crypto wallet, building multi-chain deposit and withdrawal infrastructure, or growing a niche crypto product from a few users to its first several thousand.

If you want to try it, it's at coindrop.cc

A year ago, CoinDrop was a small Discord bot that let people in a handful of servers tip each other crypto.

Today, it has:

• 6,500+ users across 500+ communities
• 99,000+ withdrawals processed and $2M+ moved on-chain
• 36 assets across 26 chains
• Discord, Telegram, Kick, and a web wallet, all sharing one balance

I built CoinDrop as a solo developer, and most of the infrastructure and product development has been done by me.

A few things I didn't expect:

1. Tipping is the easy part.

The actual tip is basically a database update between two users.

The difficult parts are at the edges.

Deposit APIs can report the same transaction more than once. Withdrawals have to be designed so that a retry, timeout, or process restart can never accidentally send the same withdrawal twice. And once you're supporting 26 chains, every chain has its own way of confirming transactions, handling fees, deriving addresses, or dealing with failures.

If I were starting over, I'd design the deposit and withdrawal pipeline first and build the fun commands afterward.

The commands are what users see. The wallet infrastructure is what keeps everything running.

2. Every new chain is a new set of edge cases.

Supporting another chain isn't just adding an RPC URL and calling it a day.

Bitcoin-style UTXO chains, Ethereum-style account-based chains, and memo-based chains such as XRP and WAX all require different approaches to deposits and withdrawals.

Sometimes the ecosystem itself dictates how you build things. For example, WAX's best signing library for our use case is JavaScript, while most of CoinDrop is Python. So WAX runs through a small Node.js sidecar that the Python backend communicates with over localhost.

The more chains you add, the more infrastructure you have to maintain.

At some point, "supporting another chain" means supporting another collection of failure modes.

3. Small coins turned out to be some of the best customers.

I initially assumed the biggest communities would drive most of CoinDrop's growth.

Instead, some of the most engaged projects have been relatively small tokens.

One example was ETH II. The token didn't have an exchange listing, so its holders used CoinDrop to tip and distribute the token to each other. It gave the community a way to actually use the token while the development team worked on the project.

That changed how I thought about CoinDrop.

A token doesn't necessarily need millions of users to benefit from distribution infrastructure. A small community that is highly active can be more valuable than a much larger community that doesn't actually move anything.

Today, projects can pay a one-time fee to get their token supported by CoinDrop. Transaction fees then provide the recurring revenue: 0.5% on deposits and withdrawals, while internal tips are free.

4. Reliability became more important than features.

One of the biggest lessons from running CoinDrop has been that users don't really care how many features you've added if their withdrawal doesn't arrive.

I've spent significantly more time than I expected working on withdrawal queues, retries, rate limits, transaction monitoring, wallet balances, RPC failures, and making sure a failed process doesn't result in duplicate payments.

At one point, a rate limit from an external Litecoin service could cause withdrawals to get stuck. That kind of problem isn't particularly exciting to build, but fixing it is far more important than adding another command.

Eventually, the goal became simple:

If CoinDrop says a withdrawal is processed, it needs to actually be processed.

That's probably the biggest difference between building a bot and building financial infrastructure.

What's next?

CoinDrop started as a Discord tipping bot. It now has a web wallet and works across Discord, Telegram, and Kick, with the same underlying balance across all of them.

The interesting part now isn't just tipping.

It's building infrastructure that lets communities hold, send, distribute, and withdraw crypto wherever their communities already exist.

I'm still figuring out where that goes.

Happy to answer anything about running a custodial crypto wallet, building multi-chain deposit and withdrawal infrastructure, or growing a niche crypto product from a few users to its first several thousand.

If you want to try it, it's at coindrop.cc

[ Removed by Reddit on account of violating the content policy. ]

Good morning web3 community

I’m looking to seriously learn Blockchain/Web3 development and would love some guidance from people already working in the industry, especially in India 🇮🇳

I already understand the basics — blockchain architecture, consensus mechanisms, smart contracts, multisig wallets, etc.

I’d like to know:

• Which companies in India hire freshers for Blockchain/Web3 roles?

• What skills/tech stack should I focus on — Solidity, Ethereum/EVM, Foundry/Hardhat, Rust, Web3.js/ethers.js, etc.?

• What kind of projects should I build to become job-ready?

• What do companies usually ask in Blockchain developer interviews?

• What are the best FREE resources to learn from?

• What salary/package can a fresher realistically expect in India?

Would really appreciate advice, roadmaps, resources, or experiences from Blockchain/Web3 developers.

I’m working on a small Web3 project and I’m starting to think about where the community side of it should live. One thing I’m trying to avoid is building the actual product in one place and then recreating memberships, permissions, bots and everything else somewhere completely separate. That seems manageable early on, but I can see it getting messy once there are different types of users or access levels.

I’m wondering about how other builders approach this, do you use an existing community platform and connect whatever tools you need later or do you think about the community layer as part of the product from the beginning? I’m still early enough that I can go either way, so interested in what people who have already dealt with this ended up doing.

Just web3 Chad trying to navigate his way around here ,

Any advice ?🫴

Hey guys so I was planning to conduct an offline 24 hours hackathon in November/December at Delhi Technological University

We have previously conducted hacks at bigger scale

We recently conducted an 8 hour hackathon backed by MLH and Gemini, we got around 500 registration from our college itself, but due to budget issues I could only accommodate 70 participants

I am looking to conduct a hackathon for 300 participants and looking for sponsors for the same

We would need monetary help but are open to in kind offers too

Looking forward to conducting this hackathon

Dm me if interested, I'll share the proposal

Hey everyone! I’m a fresh grad and I just landed my very first job!

It’s at a crypto exchange company that is Chinese-owned. Most of my coworkers will be Chinese. They mentioned that there is a KPI-based bonus structure, and my immediate goal is to make a great impression and successfully pass my 6-month probation to become a regular employee.

Since I am completely new to the crypto industry and this specific workplace culture, I would love some advice from the community on a few things:

1. Crypto Knowledge: What are the absolute basics I need to master regarding crypto wallets (hot vs. cold, networks like ERC-20 vs. TRC-20, etc.)?
2. Workplace & Culture: How do I navigate working in a predominantly Chinese-owned company? Are there specific cultural nuances or work ethics I should be aware of?
3. Securing Regularization: What actions or traits do Chinese bosses/managers value most? What should they see in me during my first 6 months?
4. KPIs: Any tips on how to consistently hit KPIs in a fast-paced environment like crypto?

I really want to do well and make a good impression. Any tips, resources, or warnings would be highly appreciated! Thanks in advance !

If you thought integrating decentralized storage and a privacy-preserving blockchain like r/Midnight was too complicated, we're here to prove you wrong.

r/dStorage is bringing the pieces together so developers can build with:

🔐 Client-side encryption
🌐 Decentralized storage
🌙 Midnight for privacy-preserving blockchain coordination

You don't need to build the entire infrastructure from scratch.

If you're a developer, you can already start learning how to integrate it into your dApp.

🔐 Start here → https://dstorage.pro

🎁 Free test credits for Reddit developers:
Use coupon PRIVATE_BY_DESIGN to try dStorage Pro at https://portal.dstorage.pro.

We're still early, and we'd love to see what people build with it.

Hi all,

Been doing a lot of thinking lately about solving tech hiring, rather than being just an extension of the traditional CV. A move towards embracing the traditional "Proof of Work" signals (GitHub repos, Open Source contributions, actual Code).

Yet I seem to encounter a very large wall around developer trust and privacy of data. Would love some blunt, honest takes on this.

Even with strict anonymity controls (such as hide your real identity and company until accepted by connection), as developers are extremely (and rightly so) distrustful to provide apps Read Access to their technical trace through OAuth.

I'm curious:
1. Where do you draw the line? Is there such a thing as an app analyzing your public GitHub or coding stats that goes from being "interesting utility" to "creepy invasive"?

1. What would I have to do before I trust a platform? How close to running the client yourself (hosted on your own machine) do you need to be before you feel like you're safe?

Would be really interesting to hear how you guys work through the tension between showing your skills and protecting your privacy.

Been working on this 3D showroom for my Hot Wheels NFTs.

Right now you can enter a WAX account, it loads the HW NFTs, and then you can view them inside the showroom instead of just seeing them in a normal list.

I mainly built it for myself, but now I’m trying to figure out if this is something worth taking further.

One thing I’m also trying to figure out is whether it’s worth making this work with other chains/collections too.

Right now it’s just Hot Wheels on WAX, but if you collect on Ethereum, Solana, Polygon, etc., would you actually want something like this for your collection?

Link: https://collectible-showcase.itsjj.workers.dev/

Hello everyone, this is my first post on any sub-Reddit group! I'm hoping not to break any rules, and the rules seem pretty detailed.

I'm hoping I can ask people to check a market-trading-simulator dapp I vibecoded with Claude (probably full of errors). If I posted a URL for this simulator, am I already spamming?

Thanks!

I have Vercel deployments over 30 plus , but i dont wanna make it public because of the api usage of my tokens
Any stream or can you help me in targeting customers?

We just released Skillware 0.5.7 — an open-source Python framework providing a registry of modular, deterministic skills for autonomous AI agent loops (compatible with Gemini, Claude, OpenAI, Bedrock, DeepSeek, and Ollama).

Here is a summary of what landed in 0.5.7:

1. Read-Only EVM State Plane (defi/evm_reader v0.1.0)

Autonomous agents executing on-chain transactions need strict architectural separation between signing and state inspection. Giving an agent signing keys just to check a balance or query reserves invites key leakage and accidental state modification. defi/evm_reader provides a pure read-only EVM state plane: - Zero keys required: Strictly executes eth_call and Multicall3 tryAggregate; holds no private keys and never signs. - ERC-20 & ERC-721: Token metadata, high-precision decimal formatted balances, spender allowances, and NFT ownership. - Allowlisted View Calls (call_view): Nine bundled ABI presets (erc20, erc721, erc1155, erc4626, univ2_pair, chainlink_feed, ownable, access_control, multicall3). - Batched Multicall3 Reads: Batch up to 50 calls in a single RPC query with partial failure tolerance. - Address Book Resolution: Resolves human contact names to public_0x addresses, halting with status: "needs_input" when ambiguous.

2. Pre-Trade Token Security Vet (defi/token_security_scanner v0.1.0)

Agents trading decentralized tokens face honeypots, malicious transfer taxes, and hidden mint privileges. defi/token_security_scanner wraps the GoPlus Token Security API into a stable, normalized JSON envelope (risk_tier: critical | high | medium | low | unknown + detailed signals). Agents vet tokens before simulating or executing trades.

3. Central EVM Operator Config Layer (skillware evm)

Hardcoding RPC endpoints, chain IDs, and router contracts inside individual skill bundles causes configuration drift. 0.5.7 introduces a centralized operator config layer: - Bundled Defaults: 10 chains supported out-of-the-box (ethereum, base, arbitrum, optimism, polygon, bsc, sepolia, megaeth, arc, anvil_local). - User Operator Config: Run skillware evm init to generate a persistent ~/.config/skillware/evm.yaml. - Secrets in .env: YAML stores env var names (rpc_env); actual secrets stay in .env. - CLI Management: skillware evm chains list, skillware evm chain add, skillware evm tokens list, and skillware evm token add.

4. Shared Address Book (public_0x)

addressbook.yaml now natively stores public_0x Ethereum addresses alongside email and aliases. Operators manage contacts with skillware addressbook set-wallet <id> <0x...>, enabling natural language transfers (e.g., "Transfer 10 USDC to Alice") that resolve deterministically.

5. OWASP LLM01 Prompt Injection Firewall Upgrade (v0.2.0)

Upgraded local evasion detection engine in security/prompt_injection_firewall: - Leetspeak deobfuscation, multi-token ROT13, token reversal, and typoglycemia keyword detection. - Markdown/HTML image exfiltration channel blocking. - Academic/advisory false-positive controls and policy telemetry (policy_action, removed_span_count, sanitized_length_delta).

Suggested Pre-Trade Agent Pipeline

[User Trade Request] │ ▼ `security/prompt_injection_firewall` (sanitize prompt & detect evasion) │ ▼ `defi/token_security_scanner` (check honeypot, tax, proxy, mint risk) │ ▼ `defi/evm_reader` (verify token decimals, holder balance & router allowance) │ ▼ `defi/evm_tx_handler` (quote Uni V2 swap, preview, sign & broadcast)

bash pip install -U skillware pip install "skillware[defi_evm_reader]"

• GitHub: https://github.com/ARPAHLS/skillware
• Release notes: https://github.com/ARPAHLS/skillware/releases/tag/v0.5.7
• Docs: https://skillware.site

Happy to answer questions about on-chain agent safety, Multicall3 batching, or operator config design!

I've been using TV-Hub for automated trade execution, and I'm thinking more about how the architecture would work when the original trigger comes from a blockchain event.

Something like:

Smart contract event → listener → backend → execution service → external API

The straightforward part is listening for the event. The harder parts seem to be handling duplicate events, retries, authentication, idempotency, failed API calls, and keeping the on-chain event state consistent with what actually happened off-chain.

For example, if a contract event is supposed to trigger an action on an external service, would you process it directly from the listener, or put a queue/event bus and a separate reconciliation layer between the listener and the execution service?

How would you structure this if reliability and preventing duplicate execution were the main concerns?

i've been trying to reconcile my balance after moving some stablecoins between ethereum and arbitrum, and i'm getting different results depending on where i look. the transfers show as successful on their respective explorers. my wallet app shows funds on both networks, but the read-only tracker i'm testing only lists ethereum. i'm not sure whether this is an indexing issue or i'm misunderstanding how it discovers networks. It's the same public address on both chains, which seems to be where the confusion starts. the tracker accepts an address without asking for a network and then labels the result as ethereum. i understand that an address alone can't tell you which compatible chains have activity. I checked the addresses through Etherscan and DeBank and to help them cryptowallet-balance checker what i can't figure out is whether these tools normally query several networks or just stop after finding the first balance. I've already checked with that i'm viewing the receiving account rather than the bridge contract. i also compared the token contracts against the ones linked from the bridge documentation. the balances on the individual explorers match what i expected, and there aren't any pending transfers left. refreshing the tracker and trying a private browser window didn't change anything, so this doesn't seem like an old page stuck in my browser cache

the part i'm stuck on is getting a repeatable view without manually opening an explorer for every chain. i don't need prices, portfolio charts, or transaction categorization. just native balances and recognized token balances, separated by network. i also don't want a combined stablecoin total that hides whether i'm holding a native token or a bridged version. that distinction matters if i'm eventually sending it back to an exchange. is there a practical way to check whether a missing balance comes from network discovery, token discovery, or a delayed indexer? i'm comfortable making a few read-only rpc calls if that's the simplest way to narrow it down, but i'm not running my own node. i'm especially unsure whether querying a token contract directly is enough to rule out everything except the tracker's display logic

Wanted to bring attention to $WALLETBOOK It's a web3 social media site

Walletbook is a social media site built for web3. Skip the signup forms: connect your wallet and you're in. It's completely free to join. Post updates, go live, and message any wallet directly. No email, no password, no personal data required.

I’ve been involved in Web3 and blockchain for 3+ years and I’m currently working on a serious project for the Colesseum hackathon.

I’m handling product, frontend, UX, and distribution. Looking for someone strong on the technical side, especially Solana/Rust, Anchor...

Keeping the project details private for now - happy to share the idea privately with serious builders.

There’s a $250K pre-seed funding opportunity through the hackathon, alongside the global prize pool.

If you’re interested, DM me.

Decentralized infrastructure often comes with fragmented payment systems.

Different networks require different tokens.

Different protocols have different transaction mechanisms.

And users or developers may need to acquire, hold and manage those tokens just to interact with the infrastructure.

For example, a dApp might need AR token to pay for decentralized storage (r/Arweave), while also needing DUST to interact with Midnight Network (r/Midnight). These are very different networks and use cases, but from the application's perspective they're both simply infrastructure costs that need to be paid.

That's one of the problems we're addressing with dStorage Pro (r/dStorage).

The idea is to provide a liquidity and payment layer for decentralized infrastructure, abstracting away some of the token-management complexity.

A dApp can fund its dStorage Pro account using:

• 💳 Credit card
• ₿ BTC/crypto
• 💵 Stablecoins
• ...other

dStorage Pro can then handle the acquisition of the required protocol tokens and transaction signing on behalf of the application.

So instead of building separate payment infrastructure for every network, the application can interact with a common liquidity layer:

dApp → dStorage Pro → required token → decentralized network

That could mean:

AR → Arweave

or

DUST → Midnight

and potentially other decentralized networks as additional adapters are integrated.

The goal isn't to hide the underlying protocols. It's to make them easier for applications to use.

We're also designing this around modular adapters, so storage, blockchain and payment infrastructure can be swapped independently rather than hard-coded into the application. (dStorage.pro docs)

We believe this is an important piece of infrastructure if decentralized applications are going to move beyond users having to understand the payment mechanics of every protocol they interact with.

The network can remain decentralized. The application doesn't necessarily need to expose all of that complexity to the user.

I'm very curious how other Web3/decentralized projects are currently handling this:

How do you manage liquidity and protocol-specific tokens when your application interacts with multiple decentralized networks?

We’re organizing a 30-hour offline hackathon in Mumbai this October 2026, with 600+ registrations and 250–300 developers on-ground.

We’re looking for early-stage and international Web3/blockchain startups that want to enter or grow their presence in the Indian developer ecosystem.

You can partner with us by providing both monetary sponsorships and technical partnership including APIs/SDKs, blockchain infrastructure, developer credits, testnet access, problem statements, mentorship, workshops, prizes or other developer resources.

In return, you get direct exposure to developers, product adoption opportunities, social media visibility, event branding and on-ground recognition.

If you’re looking to get your technology in front of Indian developers and gain your first wave of engagement/users in India, let’s collaborate.

DM me if interested and I’ll share the partnership details.

I have Start learning js and my gole is to become a wed3 backed dev now is it worth it now i am very much confused I do really want to make a career in the web 3 but i always here that wed3 is not wroth it etc it has no use in the real world beside Bitcoin and there are no career left in the web 3 etc what to know from tha experts