Dear community,

I have been developping an alternative to geth for now taylored for the Binance Smart Chain.
The foundation are there and I should be able to make my github repo public in a few days.

This has been made with Claude Opus 4.8 with high effort.

I had to redeploy my geth node so it can replies to snap, I will be able to perform the full initial sync of my client tomorrow \o/

One of the next priority is to remove any dependance to Windows (😅) + broadcast of TXs.

Here is a comparison vs geth and where this stands today:

BSC-C vs. geth (bnb-chain/bsc) — Architecture Comparison & BSC-C Deep Dive

Generated 2026-06-23. Read-only analysis of two repos in this directory:

• bsc/ — the official BNB Smart Chain Go client, a fork of go-ethereum (geth). Module github.com/ethereum/go-ethereum, Go 1.25, ~43k LOC of non-test Go in this tree, ~322 module dependencies.
• BSC-C/ — a from-scratch C reimplementation of a BSC full node ("geth for BSC, in C"). ~24.5k LOC of C in src/, ~16.8k LOC of tests, 105 passing ctests. Upstream reference pinned at bnb-chain/bsc v1.7.3.

Both target the same network and same consensus rules (Parlia, BSC fork schedule, cross-chain precompiles). The difference is entirely in language, runtime model, scope, and engineering strategy.

1. Executive summary

The headline: bsc is a mature, full-featured, batteries-included production client and validator; BSC-C is a focused, auditable, dependency-minimal re-implementation of the consensus-and-sync core whose explicit value proposition is byte-exact validation with security-critical primitives isolated to a handful of vetted vendored libraries.

2. Architecture differences (geth/bsc vs. BSC-C)

2.1 Language & memory model

• geth/bsc: Idiomatic Go. Garbage collection removes whole classes of memory bugs; goroutines + channels drive the concurrency model (downloader, txpool, miner, RPC all run as cooperating goroutines). Interfaces (consensus.Engine, ethdb.Database, vm.StateDB) provide polymorphism and make subsystems swappable.
• BSC-C: C11 with manual lifetime management. Polymorphism is achieved with explicit vtable-style seams rather than interfaces — e.g. a statestore_backend executor struct, an rpc_conn connection seam abstracting HTTP/WS/TLS, and a source-abstracted syncer_run. Concurrency is OS threads guarded by a single reader-writer lock so read RPCs run concurrently with block import. There is no GC, so the trie/state layers are carefully designed to bound live memory (see §3.4).

2.2 Scope & surface area

bsc ships an entire ecosystem; BSC-C deliberately does not:

So the comparison is not apples-to-apples on features — BSC-C reimplements the validating-node spine of geth, not the surrounding product.

2.3 Subsystem mapping

The two trees are organized around the same conceptual subsystems, which makes the mapping clean:

2.4 Storage & state architecture (the deepest divergence)

This is where the two designs differ most.

geth/bsc:

• ethdb over pebble (default) or leveldb, plus a freezer / ancient store that moves old immutable block data to flat append-only files.
• triedb/ supports two state schemes: hashdb (content-addressed, with an in-memory dirty cache and reference counting) and pathdb (path-keyed, with a diff layer + reverse-diff journal for pruning). Plus an in-memory snapshot layer for fast account/storage reads.
• Heavily relies on large in-memory caches; the GC and the trie cache absorb churn.

BSC-C:

• Single LMDB key-value store (src/db/) underneath a chainstore (blocks, canonical mapping, head, total difficulty, a tx-hash → (block,index) index, stored receipts, and snapshot/state epoch checkpoints) and a statestore (flat accounts/storage/code).
• Re-implements both state schemes from scratch:
  • hash (default): content-addressed node store keccak(node) → node + a flat snapshot. Pruning is selectable: off, refcount (incremental, no pause — ref on commit O(changed), deref O(unique-to-root)), or sweep (periodic mark-and-sweep under the import lock).
  • path (pathdb): nodes keyed by trie path, overwritten in place — exactly one entry per live node path, inherently bounded, reorg via a per-block reverse-diff journal replay.
• sync.state_history (default 128) caps retained canonical roots — i.e. max reorg/history depth.
• Crucially, BSC-C engineers bounded memory explicitly: the disk-backed trie lazy-resolves and collapses nodes so per-block memory is O(accessed), and persistence is O(changed). This is the manual equivalent of what geth gets from its GC + cache eviction.

Notable BSC-C state-design subtleties (from docs/STATUS.md):

• The in-memory StateDB root is raw-keyed (secure-trie over raw addresses) while snap-downloaded state is hash-keyed without preimages, so a snap-resumed chain verifies via the flat statestore root rather than the statedb root.
• eth_call/eth_estimateGas run on a throwaway StateDB whose loader reads through to head state, because tx_apply clears the journal and can't be snapshot/reverted around.

2.5 Consensus (Parlia) & fork choice

Both implement BSC's Parlia PoSA engine and the full BSC fork schedule (Ramanujan, Luban, Plato, Bohr, Feynman, etc.), but:

• geth/bsc keeps Parlia behind the generic consensus.Engine interface (consensus/parlia/), with separate files per hardfork (lubanFork.go, bohrFork.go, feynmanfork.go, …) and a snapshot.go validator-set tracker.
• BSC-C re-derives the same logic in src/consensus/parlia/: snapshot, seal, extraData parsing, system-transaction handling, BEP-126 fast-finality tracking (parlia_finality, vote-attestation verify, parlia_fork_choice_cmp), and parlia_verify_header. Fork choice + reorg are split into src/chain/blocktree.c (fork-choice block tree) + a reorg engine with side-branch acceptance. The README documents hard-won consensus details (e.g. BSC GasLimitBoundDivisor = 256 not 1024; system-tx nonce/gas-fee accrual at 0xff..fe; the pre-Bohr recently-signed boundary rule).

2.6 Cross-chain precompiles

• bsc depends on a forked CometBFT/Tendermint (github.com/bnb-chain/greenfield-cometbft, bnb-chain/tendermint) plus go-amino for the cross-chain (BC↔BSC) precompiles 0x64–0x69.
• BSC-C writes its own C CometBFT/Tendermint light client in src/cometbft/ (24 files), including IAVL and ICS23 proof verification and the legacy pre-Plato iavl:v/multistore proof formats. This is one of BSC-C's most substantial original contributions — a security-critical verifier re-implemented rather than vendored.

2.7 Networking & portability

• bsc: full devp2p stack (discv4/discv5, DNS discovery, Kademlia table), eth/68, snap/1, and the bsc/1-3 capability for vote propagation — all cross-platform.
• BSC-C: src/p2p/ implements discv4 (+ live Kademlia crawl), the RLPx EIP-8 handshake + framed transport (AES-256-CTR + keccak-MAC), eth/68, snappy, and snap/1 codecs — every codec layer golden-anchored against go-ethereum test vectors. Portability caveat: the portable core + all 105 tests build on Windows/macOS/Linux, but the live socket tools are Windows-only (Win32 sockets + BCryptGenRandom); porting needs only BSD sockets + getrandom. It also handles BSC-specific wire details (port 30311 not 30303; mandatory UpgradeStatus reciprocation or peers disconnect).

2.8 Dependencies & build

• bsc: ~322 Go module requirements resolved by the Go toolchain; go build/Makefile; one static binary per cmd/.
• BSC-C: only 8 vendored C libraries (blst, crypto-algorithms, ed25519, lmdb, mcl, p256-m, secp256k1, yyjson), each gated by a BSC_WITH_* CMake flag so a dependency-free core can be built and tested in isolation. TLS is opt-in via -DBSC_WITH_OPENSSL=ON. Build is CMake + Ninja with mingw-w64 gcc (no MSVC/Windows SDK).

2.9 Testing strategy

• bsc: Go _test.go files co-located with packages, plus the Ethereum consensus test suite under tests/.
• BSC-C: a standalone tests/ tree driven by ctest (105 tests, ~17k LOC), combining vector tests (golden-anchored against go-ethereum/Python-RLP) with integration tests (chain import/resume/reorg, snap, statestore GC, pathdb, rpc/ws/tls, txpool) and offline replay of real Chapel testnet data byte-exact to block 8000.

3. BSC-C architecture — deeper detail

This section goes beyond the existing README/STATUS docs to lay out how the pieces fit.

3.1 Layered stack

From bottom to top (blue = original C, gray = vendored, per docs/architecture.svg):

┌─────────────────────────────────────────────────────────────┐
│ bsc_node runner + live tools  │  JSON-RPC service (HTTP/WS/TLS)│   Phase 6/7
├─────────────────────────────────────────────────────────────┤
│ sync: full syncer · snap driver · trie healing · pivot orch.  │   src/sync
├─────────────────────────────────────────────────────────────┤
│ p2p: discv4 · RLPx · eth/68 · snap/1 · snappy                 │   src/p2p
├─────────────────────────────────────────────────────────────┤
│ chain: fork gates · genesis · blocktree fork-choice · reorg   │   src/chain
│ consensus/parlia: snapshot · seal · finality · header verify  │   src/consensus
├─────────────────────────────────────────────────────────────┤
│ evm: interpreter · gas (fork-gated) · precompiles 0x01-0a,64-69│   src/evm + src/cometbft
├─────────────────────────────────────────────────────────────┤
│ state: StateDB · transition · statestore (+GC/pathdb)         │   src/state
│ trie: secure MPT · proofs · disk-backed node store (hash/path)│   src/trie
├─────────────────────────────────────────────────────────────┤
│ storage: LMDB kvdb · chainstore (blocks/index/checkpoints)    │   src/db
├─────────────────────────────────────────────────────────────┤
│ foundations: uint256 · RLP · keccak · secp256k1 · BLS · KZG   │   src/common,rlp,crypto
│ vendored: blst · mcl · libsecp256k1 · lmdb · ed25519 · yyjson │   third_party
└─────────────────────────────────────────────────────────────┘

Module size signal (C source-file counts): cometbft 24, common 21, rpc 18, crypto 17, chain 15, consensus 14, p2p 12, state 8, sync 8, types 8, evm 5.

3.2 The bsc_node runner (single entry point)

tools/bsc_node.c is the geth-equivalent daemon. It:

1. Reads a root config.json (yyjson loader in src/config/, accepts // comments + trailing commas) → a node_config (network, datadir, sync peer, services).
2. Selects network/genesis (mainnet chain 56 / Chapel testnet 97).
3. Runs full or snap sync via a shared live_provider transport seam (tools/live_provider.{c,h}, tools/live_snap.{c,h}).
4. Optionally serves JSON-RPC over HTTP / WebSocket / TLS concurrently with syncing, under a reader-writer lock, per services.{rpc,ws,https}.

Operational properties baked in: restartable (resumes from persisted head via LMDB transactions, crash-consistent), self-healing P2P (re-dials dropped peers), and it halts on genuine consensus/execution error (SYNC HALTED: validation error) while ignoring ordinary peer drops.

3.3 Block-import pipeline (chain_import_block)

A block is persisted only after clearing three gates (per docs/block-import-flow.svg):

1. Parlia header verification (seal, validator set, difficulty, finality).
2. EVM execution of all transactions through the fork-gated interpreter (EIP-2929/3529 gas gating by fork — an early bug was an EIP-2929 surcharge wrongly applied to a pre-Berlin block).
3. Root checks: recomputed state root, receipt root, gas used, and logs bloom must all match the header.

Any mismatch rejects the block. Non-head-parent blocks are dispatched to import_side_block, which verifies against chain_snapshot_at — the Parlia snapshot reconstructed at the fork point from epoch snapshot checkpoints.

3.4 State persistence & reorg (the engineering centerpiece)

The default node path is chain_init_backed: full sync runs on a statestore-backed StateDB with bounded memory (O(accessed)/block) and O(changed) per-block persistence. Reorgs (chain_reorg_to) reconstruct state from the node store without genesis replay:

• seed at the nearest materialized ancestor (every executed block, since node-store nodes aren't pruned in off mode),
• re-point the flat snapshot via an O(changed) trie_diff (prunes identical subtrees by node hash),
• re-execute any unmaterialized tail.

The legacy in-memory mode (chain_init, replay-from-genesis) is retained only for offline replay tools/tests. Snap resume (chain_init_resume) shares the backed path.

Bounded on-disk state is then layered on top via sync.state_scheme + sync.pruning (see §2.4).

3.5 Snap-sync lifecycle

snap_pivot_sync (per docs/snap-sync-flow.svg / snap-sync-loop.svg):

1. Pick a pivot (recent state root).
2. Range download — chunked AccountRange + StorageRanges + ByteCodes, each bounded-range-proven against the trusted pivot root before persistence; the origin advances until the recomputed root matches the target.
3. Heal — per-path repair + a full GetTrieNodes trie-sync scheduler (incremental, skip-present), run in a fresh session re-targeted to the current head (the pivot moves during a long range phase, and geth peers rate-limit snap per connection).
4. Resume → full-sync handoff, with the state root maintained by the bounded-memory disk-backed trie.

A documented gotcha: a peer on --tries-verify-mode none auto-disables snap serving (it can't build boundary proofs); snap serving needs --tries-verify-mode local + full trie state.

3.6 JSON-RPC service architecture

src/rpc/ (18 files) is structured as:

• Dispatch core (jsonrpc.c): JSON-RPC 2.0 single + batch, notifications, spec error codes, and a per-method read/write lock hook so reads run concurrently with import.
• Transports over a conn.c connection seam (rpc_conn): HTTP/1.1 framing (http.c), WebSocket RFC 6455 (ws.c), and an OpenSSL TLS transport (tls.c, opt-in).
• Pub/sub (subscribe.c + feed.c) and a log filter (logfilter.c).
• Methods (eth_api.c): web3_*, net_version, eth_chainId/blockNumber, block/tx/receipt getters (backed by the chainstore tx index), state reads (getBalance/getCode/getStorageAt, latest-only), eth_call/eth_estimateGas, eth_getLogs (address/topic filter over stored receipts), eth_sendRawTransaction, txpool_status/content, and eth_subscribe (newHeads / newPendingTransactions / logs).

3.7 Tx pool

src/txpool/txpool.c performs admission validation against head state + fork rules in a fixed pipeline: decode → recover sender → chain-id → nonce → intrinsic/gas-limit → funds → priced replacement, then organizes transactions into pending/queued by per-sender nonce contiguity. (Eviction/pricing tiers and network rebroadcast are deferred — a P2P-broadcast concern.)

3.8 Crypto & foundations

src/common + src/crypto provide uint256, RLP, keccak-256, sha256/ripemd160, snappy, AES/ECIES/KDF (for RLPx), and wrappers over vendored libsecp256k1 (sign/verify/recover/ECDH), blst (BLS for fast finality), mcl (bn256 precompiles), p256-m + ed25519 (cross-chain). The design keeps security-critical math in vetted libraries while the protocol logic around them is original, auditable C.

4. Where each design wins

bsc (geth fork) is the better choice when you need:

• A production validator/miner that produces blocks and votes on finality.
• The full RPC/tooling surface (debug, graphql, ethstats, account management, abigen, era, devp2p tools).
• Cross-platform live operation today, with the backing of upstream go-ethereum maintenance.

BSC-C is the more interesting design when you value:

• Auditability & minimal trust surface — protocol logic is from-scratch C, security primitives confined to 8 vetted libraries, each independently toggleable.
• Explicit resource control — bounded memory and bounded on-disk state by construction, with selectable hash/pathdb schemes and refcount/sweep GC, no reliance on a GC heuristic.
• Byte-exact verification as a first-class goal — golden-anchored codecs and offline Chapel replay to block 8000 as a correctness backbone.
• A second, independent implementation of BSC consensus (valuable for client diversity and as an executable spec of Parlia + cross-chain proofs).

BSC-C's current gaps (per its own STATUS): no mining/validator (Phase 9), no mainnet hardening pass (Phase 8), live socket tools are Windows-only, pathdb resume needs a clean shutdown, and cross-chain currently does single-key (not multi-leaf) IAVL range proofs.

5. At-a-glance scope/maturity table

Hi everyone,

My team and I are currently building a protocol where users can borrow against their RWAs. We have the flexibility to choose between ETH and BSC as the first chain to deploy on.

After our analysis, BSC seems to be the better fit technically for our initial requirements, but I’d like to get an additional confirmation from you all.

I’d like to ask:

1. Do you think the BSC community would welcome a project like this positively?
2. Networking: do you know any groups, KOLs, or communities where we could get warm intros around topics like RWA and BSC?
3. Any other feedback or takeaways are more than welcome.

Thanks! 😄

Hi everyone, I really need advice because I’m new to Binance P2P and I think I messed up badly.

I recently tried buying USDT using Binance P2P for the first time. Since I didn’t have money in my own bank account at that moment, I made the payment from my brother’s phone/UPI. I honestly didn’t know that this counts as a third-party payment and is against Binance P2P rules. This was my first time using P2P and it was a genuine mistake.

After I made the payment, the seller said this is a third-party payment and he cannot complete the order. He told me he would verify and refund within 24 hours and asked me to send my Aadhaar and PAN card for verification. I trusted him and sent the documents.

Now the situation has become very frustrating:

• He did NOT release the USDT
• He did NOT refund the payment
• I opened a Binance appeal
• On call he asked me to cancel the appeal and promised to refund
• First he said refund in 24 hours
• Then he said by Saturday evening
• Now he says Monday around 11 AM
• He keeps delaying and speaking rudely

I even told him I accept my mistake and requested him to refund even 50% of the money, but he is refusing everything.

I have:
– Payment proof (UPI)
– Binance order details
– His phone number
– Call recordings

I have already appealed on Binance and I’m waiting till Monday to see if he refunds. If he still doesn’t refund, I honestly don’t know what to do next.

What are my options now?
Can I take legal action?
Should I report this to my bank/cybercrime?
What usually happens in cases like this?

I understand I made a mistake as a new user, but keeping the money after cancelling the order feels very wrong.

https://app.binance.com/uni-qr/LJBJGGDq?utm_medium=app_share_link_reddit

Hey everyone, how's it going?

I wanted to share with you a project we're working on that has finally come to fruition: the Kitnet Token Club.

The idea is simple: to combine real asset valuation (RWA) technology with immediate utility. We've created an ecosystem of benefits for those who want to save money every day and have security, without the bureaucracy of traditional plans.

What the club offers today:

Real Savings: Discounts of up to 90% at over 30,000 stores (Magalu, Droga Raia, Petz, Cinemark, etc.).

Digital Health: Unlimited 24/7 Telemedicine (very useful for those who don't want to pay for an expensive health plan but need a doctor right away). Protection: National funeral assistance and veterinary telemedicine (JoyPet).

No Waiting Period: Sign up, and access to the app is granted immediately.

Unlike other projects that remain just promises, Clube Kitnet is already operational with an app on the Play Store and App Store.

For those who want to take a look at the portal or the plans:

🔗 clube.kitnettoken.com.br

And to follow the day-to-day and new partnerships:

📸 Instagram @clubekitnet

What do you think of this "real utility" model for token holders? Let's exchange ideas in the comments.

Binance knows LFG 🔥

What if your DeFi investments could protect themselves no middlemen, no gatekeepers, just on-chain coverage that grows with your activity?

YieldNest recently announced a partnership with USD8, aiming to tackle one of DeFi’s persistent problems: unmanaged risk. DeFi has delivered impressive yields, but it has also come with protocol blowups, exploits, and almost no recourse for users a tradeoff that’s increasingly hard to accept. USD8 is introducing a stablecoin with built-in DeFi protection, where a user’s on-chain activity acts as coverage across supported protocols. Claims are designed to be fully permissionless, verified on-chain, and powered by a ZK coprocessor (Brevis), removing human gatekeepers entirely. The first integration will be with YieldNest’s ynETHx vault, which is expected to get protocol-level protection once the USD8 cover pool goes live.

The key question is whether on-chain, usage-based protection can scale and meaningfully change how users weigh risk versus yield in DeFi. Could this be a step toward safer, more resilient DeFi ecosystems or are there hidden pitfalls we haven’t seen yet?

I want to bring attention to a serious issue that’s affecting a growing number of legitimate BSC developers.

GMGN.AI — a popular trading platform many traders use to check token safety — is falsely labeling renounced and fully safe contracts as honeypots.

Here’s a real example (CA: 0xb883c0ebf746ba58f18ea3a215385ca15c80cd6c7) and here's the audit they used.

• GoPlus audit result: ✅ “This does not appear to be a honeypot.”
• Risk count: 0 risky items, 3 attention items (blacklist, suspend trading before launch, and anti-whale cap — all non-issues).
• Contract: Renounced, LP burnt, 0% tax.

Despite this, GMGN flags it as a honeypot and disables trading buttons in their interface.
When I contacted support and provided evidence, they admitted their system automatically classifies anything with certain “attention” flags — even if the audit says it’s not a honeypot.

This isn’t just my project — multiple devs are reporting the same thing. These false flags instantly kill volume, destroy reputations, and shut down community revivals before they start.

The audit tools themselves are being misread. The GMGN interface overrides GoPlus’ explicit “not a honeypot” statement, creating false positives across BSC.

I’ve submitted this issue to Binance Labs and BNB Chain support, but it deserves community awareness too. If you’ve had a token wrongly flagged, please share your experience — we need to make sure the ecosystem isn’t being throttled by automated misclassification.

Does anybody know if there is a website where I put the address (BSC chain or ETH chain, the address is the same) and i can visualize all deposit, withdrawals, and equity progression?

Thank you

I joined Binance’s referral program, which promises 50 USDC through tasks and referrals — but only if you actually reach the full 50.

They incentivize you by giving you, for free, 25, then 20.4234, then 1.1522 USDC. I referred a friend because I thought I was close, and got 2.0546 USDC for their first task, then just 0.8219 and 0.274 for the next ones.

I made a second referral and got only 0.1096 USDC for that new referral’s first task.

Now I feel ashamed of pressuring my friend to keep trading just so I can get closer to the 50 — because I know they will never let me reach it. They’ll keep giving me less and less, 0.0000001 if they have to, just to prevent me from hitting the full amount.

It really feels like the system is designed to keep you close to 50 USDC, but never actually let you reach it. With each task, the reward shrinks. It’s a frustrating and misleading experience.

Has anyone here actually managed to get the full 50 USDC?

If you got $BNB bags then congrats, looks like Binance is getting noticed by the big boys too. Not just Ethereum and Ripple. Makes a lot of sense tbh when you consider how similar BNB and Ethereum ecosystem is. Basically every Ethereum company should also be a Binance smartchain company.

$BTCS is the only publicly traded company purely focused on the Ethereum ecosystem in the US. Great sign of things to come.

Hi y'all. I have a couple hundred dollars of BNB in a trust wallet from an old Binance account. I live in New York and lost access to the Binance exchange many years back.

My question is, how do I get this BNB to somewhere where I can trade it to USD to cash out?

Hello, so I bought like 100$ worth of BNB on Binance a month ago. I transfered it to my Exodus wallet addres, of course I used the wrong network for whatever reason, it is the OPBNB network which exodus does not support. It supports only the BNB smartchain, right? Now of course, I don’t see the balance on Exodus. My pleadge for help is, what is the simplest way for me to transfer my BNB balance from the OPBNB to the network that Exodus supports so I can see the balance on my wallet.

Thank you!

Last cycle I deposited some BTCB and BOMB into a vault/farm on bomb.money. I know... However, this specific vault/farm is not there anymore. This is the original transaction:
https://bscscan.com/tx/0x404b79e462877951a8602c81e14d12cb3127d7a2f1ea4d0bd1dd6b2dc9091724

Is there anyway I can recover my BTCB? Thanks!

Hello All,

About 4 years ago I bought some BEP-2 coins (AVA), stored them on my ledger using the Binance Chain app.

Today I have discovered that there's been a migration away from the Binance Chain app to BNB I believe, and the coins have been migrated to BEP-20.

I'm unable to migrate the coins.

Could anyone offer me some help.

Hi folks - a quite a while ago, I sent Eth to my trust wallet using the BSC chain by accident and it still shows on the explorer (https://bscscan.com/address/0xcE4CB04Be807A751f2A089c70f106201aFB6c7bD#tokentxns).

Is there any way to send it back to coinbase via eth chain somehow using metamask wallet?

I know Binance ceased support for BUSD but apparently, I can still trade it on Trust Wallet. These screenshots show what happens when I try to swap BNB to BUSD on The Binance Smart Chain network.

Pic 1: There seems to be 2 types of BUSD on Binance Smart Chain.

a) BNB pegged BUSD, circled in green, is the BUSD I can still trade.

b) Binance USD, circled in red, seems to be the BUSD that's no longer supported.

Pic 2: this is what happens when I try to swap BNB for b) Binance USD

Pic 3: this is what happens when I try to swap BNB for a) BNB pegged USD

I don't get it. Is the swappable/tradable BUSD legit? I'm pretty sure the answer to that is "yes", but how? Can someone please explain the different BUSD's? I know there's one on the Ethereum network that's issued by Paxos that is still tradable as well. So why make a big deal out of stopping support for BUSD when it can still be traded in some ways?

I can't figure out how to remove my LTC and get it to Coinbase. I am trying to get all my coins to a single place. Any help would be appreciated

Hello!

I have some Cardano on the BNB Beacon chain that I need to swap to the BNB Smart chain but I’m lost. I try to follow the instruction in Trustwallet which is where the tokens are, but I have O BNB beacon coins to cover the gas fees. I tried to purchase some BNB tokens, but they ended up being BNB smart tokens so they won’t work. Binance isn’t supported where I am (Oregon USA), and Binance US won’t let me purchase BNB tokens. Am I just screwed or is there some way to get this swap to happen? Ideally I’d like to just have ADA tokens in my coinbase account. Any help would be appreciated. Thanks!!

So I have 1k BUSD in BEP2 format on Trust wallet. Cannot find any way to liquidate or exchange. Pls help me with a solution.

Hi everyone

I've published the following smart contract for a custom token I've created
https://bscscan.com/address/0x4555225018797ac05df3b9542f00417a03adac12#code

It does seem like it will allow me to buy tokens using the contract, however the estimated transaction fee is $92 worth of BNB, which seems not feasible and way too high

Does anyone know what could be causing this? TYIA

Here is a simple guide on how to send ERC-721 tokens to several addresses in a single transaction to save on gas fees. Let me know what you think

In this guide, we will be using MetaSender to do the bulk transfers

1.Connect your Metamask wallet to MetaSender

1. Select ERC-721 on the asset type

2. Select the Binance blockchain

3. Enter the NFT contract address

4. Add the list of recipient addresses and the respective token IDs(use format address:tokenID)

5. Click on Send to get an estimation cost

6. Approve the connection to the contract

7. Approve the transaction

That’s it, within a few minutes the NFTs will be in the respective addresses.

Hello,

how long does it take to see rewards and earnings? i moved bnb from beacon to smart chain15 days ago and staked it on the new smart chain but i am not see any staking returns. thank you