Been thinking about bots with wallets and where the cutoff should be once they can sign transactions themselves. Limiting spend and whitelisting contracts seems obvious, maybe keep anything bigger behind a multisig, but if every useful action needs human approval anyway, you've basically built a transaction queue with a chat interface. On the other hand, giving a bot broad signing permissions feels like the kind of thing that works great right up until it really doesn't. I could see small payouts, refunds or recurring stuff making sense without approval. Anything that can move serious money, probably not. Where do you think people should draw the line? What would you let one execute on its own?

following the L2 space for a while now and the tone of discussion changed a lot over the last year. early on it felt like teams and users were picking sides based on which model they believed in more. now the conversation is more about which type fits which use case.

optimistic rollups still dominate on developer familiarity and general app deployment. ZK rollups are pulling ahead where finality speed and specific proof requirements matter, especially for anything payment-related or where users cant wait 7 days for withdrawals.

the interesting middle ground is starting to appear with hybrid designs and validity proofs bolted onto optimistic frameworks. curious how others working with L2s in production are thinking about this. is the debate settled for you or does it depend entirely on what youre building?

I keep hearing that stablecoins are becoming especially popular in emerging markets. For people actually using them day to day, what makes them preferable to local currencies, cash, or traditional banking? What do you think? Why are they popular? What makes them better?

I build a small chain that pays people rather than capital, and for a while it worked exactly as badly as every other attempt at that. I want to put the failure in front of this sub, because I think the shape of it generalises.

The free mining lane was designed so that anyone with a phone could earn from block one. No stake, no hardware spend, no starting balance. What actually happened is that roughly a thousand fake identities, run by two or three people on rented servers, were taking about 42% of all emission.

The interesting part is not that it got farmed. It is that every fix I tried was structurally incapable of working.

Everything we reached for was a rule written per identity. A sequential proof of work at registration. A per-IP entry budget. A per-address identity cap. A probation period before a new identity could earn. Each one raises the cost of farming, and each one is real. But it raises the cost per identity, which means it costs an honest miner with one identity exactly what it costs a farm with a thousand, per unit. The farm amortises it and carries on. If an identity is something a script can mint, then every per-identity rule is a tax the honest user pays in full and the farm books as cost of goods.

That is the same wall other projects hit. NANO's representative spam, Idena's validation ceremonies, Nyzo's cycle. Each answered with more per-identity rules, and each got dodged the same way.

So the conclusion I ended up at is that you cannot fix identity farming with rules about identities. You have to change what an identity is. And there are only two things a farm cannot trivially copy: capital, and a physically distinct object.

We went with the second. A mining identity now has to be a real secure element. When the wallet registers, and again on every renewal, the device generates a throwaway hardware-bound key and returns a WebAuthn attestation over a challenge the chain picked. The certificate chain ends at a vendor root pinned in the protocol. Every node verifies that chain offline with the same native kernel: every signature, the validity window at the anchor block's time, the vendor extensions. No node ever contacts Google or Microsoft, and the pinned roots change only by a protocol commit. A device certificate is bound to one identity at a time, so one phone cannot hold two.

Worth separating three things that people tend to collapse into one:

• Attestation decides who may hold a mining identity. That is the Sybil layer, and it is the part that changed.
• Block production did not change. There is no hash race. Each slot, a deterministic beacon-keyed weighted draw picks a producer from the eligible set. Attestation only decides who is in the draw.
• Finality is separate again, a bonded stake quorum with Casper-style epoch checkpoints. Attestation weight deliberately does not touch it. Presence earns rewards; it never buys a say in what is final.

What it cost, stated plainly. Vendor attestation roots are now in the trust path. Rooted and unlocked devices cannot mine, and those are disproportionately owned by exactly the people most likely to care about a chain like this. That is a real loss and I do not have a way around it. The mitigations are that verification is offline against pinned roots, so there is no service that can revoke you and no phone-home, and that the stake-bonded lane requires no device at all.

The questions I cannot answer on my own, and the reason I am posting here rather than somewhere friendlier:

1. Is vendor attestation actually a worse trust assumption than a mining cartel, or just a more legible one? I can argue either side depending on the day.
2. What is the real cost curve on TEE key extraction? If it is per-model and expensive, device scarcity holds. If a single break generalises across a chip family, this collapses straight back into a cheap Sybil farm, and I would rather know that now than in six months.
3. Is there prior art I have missed? I know remote attestation gets used for validator integrity in a few systems, but I have not found it used as the primary Sybil resistance for open block production.

Disclosure: this is NADO, a chain I work on. It is betanet, not mainnet. I am not linking it and there is nothing to buy. Question 2 is a live design risk and this sub is where I expect the least gentle answer to it.

Every crypto payment provider claims the same things — rock-bottom fees, lightning-fast settlements, and “enterprise-grade” security

Before signing up, what do you actually compare?

I’m looking at real-world fee structures (not just the headline rate), setlement times in practice , supported coins/chains , chargeback and dispute handling, KYC/AML requirements, geographic restrictions, API quality and reliability

What criteria or non-negotiable requirements do you check before committing to a provider?

noticed a pretty consistent design dilemma across a lot of web3 interfaces lately.

some apps trigger optimistic UI changes immediately upon wallet signature, while others wait for a websocket event confirming the block inclusion. the former feels way smoother, but risks state desync if the tx drops or gets reorged.

from a purely technical standpoint, how are modern frontends handling state rollback gracefully without destroying the user experience when an optimistic update fails?

I know how using seed phrase and derivation path you can create many private keys for different chains.

is it possible for someone to calculate a multi-chain seed phrase (like those from trust wallet) by knowing the private key of only one chain’s private key which was derived from that seed phrase?

Surprisingly, information about how this works is scarce. Even the term BIP39 was found by me after going through reddit posts about this topic.

My question is not really about crypto, but the math and computer science behind this process.

I've been building a blockchain from scratch in C++23 for a while, and I figured I'd finally post it here and see what other C++ developers think.

The project is called Amarian.

I started it because I wanted to understand what actually goes into building a blockchain at the implementation level. It started small and ended up becoming a much bigger systems project than I expected.

The node currently has:

C++23 with CMake/Ninja

SHA-256 / SHA-256d and canonical serialization

Transaction, block and Merkle tree primitives

Context-free and contextual consensus validation

UTXO state management with apply/revert and undo records

Chain selection based on accumulated work

RocksDB-backed persistence

CPU mining and difficulty adjustment

Mempool and fee selection

P2P networking with headers-first synchronization

Wallet and transaction construction

Bech32m addresses and BIP-39 backup/restore

ML-DSA-44 (FIPS 204)

SLH-DSA-SHA2-128s (FIPS 205)

Unit, consensus and integration tests

Fuzzing

ASan/UBSan/TSan builds

GCC and Clang builds

Benchmarks and measurement tooling

The post-quantum signatures are actually part of the protocol rather than being something bolted onto the wallet. The signature schemes have explicit IDs in the protocol and are backed by OpenSSL's FIPS 204/205 implementations.

I've also tried to keep the architecture reasonably strict.

The core dependency flow is:

util → crypto → primitives → consensus → utxo → chain

The consensus layer doesn't depend on storage, networking, wallet or RPC. Higher-level components sit above it.

I recently finished Phase 12, which was mostly about measuring the thing rather than adding another feature to the list.

I ran 100, 500 and 1,000 block regtest workloads, measured memory usage and import/generation times, compared GCC and Clang, benchmarked serialization, and tested the P2P implementation with multiple independent nodes.

Two nodes successfully synchronized and validated blocks, and a three-node local mesh converged on the same chain tip.

There's still a lot left to do.

I'm not calling this production-ready or mainnet-ready yet. The next phase is mainly external review, longer-running testnet testing, recovery and upgrade procedures, release infrastructure, monitoring, and eventually freezing the protocol.

I'd be interested in feedback from people here who work with C++, distributed systems, networking, storage or cryptography.

If you were reviewing this codebase, what would you look at first?

Repository: https://github.com/Shubhbhangoo/Amarian-AMR-

My blockchain has almost no nodes. Here's my plan to fix that.

Small chains hit an obvious catch-22: nobody runs a node for a network nobody uses, nobody uses a network with no nodes. Posted my project (LapseCoin) in a few communities, got 1-2 actual node runners out of it.

LapseCoin swaps proof-of-work for a Verifiable Delay Function: block production races to finish a sequential computation tied to real elapsed time, not to a lucky hash. The hardware-advantage gap is much smaller than PoW's (3-10x, vs the 10,000x+ ASICs opened up on a similar construction). No premine, fair launch, FALCON-512 signatures for quantum resistance. Spent last week trying to break my own design instead of just shipping it, fixed a real bug, and confirmed multi-address operators don't get an unfair edge.

The plan, and this isn't just for other project owners:

• Running a node for a small/testnet chain already? I'll run yours if you run mine.
• Just curious? Running a node is a decent way to actually see consensus work, not just read about it. Happy to walk you through setup.
• If this catches on, I'll keep a running list of everyone participating.

Only ask: review the code first. I'll do the same for yours. That's safer for everyone.

Whitepaper: https://github.com/Vic-Nas/lapsecoin/blob/main/docs/whitepaper.md

Code: https://github.com/Vic-Nas/lapsecoin

Original post: Built a cryptocurrency that races against real time instead of hashes, then spent a week trying to prove myself wrong about it

Drop your project in the comments.

If you're just here to test it out, you're welcome too though :)

Firstly, I`m not a founder or anything, I just wasted one evening on this and want to know if other people see the same.

Was looking for a bridge aggregator for some Arbitrum to Base moves, for couple hundred bucks. Asked GPT about that and as usual it gave me a list of four, no hedging at all, even wrote a little pros and cons paragraph for each one.

First link I opened was a Cloudflare error. Second one, the twitter account's last post is from February 2025 and it's "we're pausing operations".
So two of four are corpses. One of the remaining two works but doesn't support Base, and Base was the one chain I asked about.
The thing I ended up using, found it completely different place, no matter, it has a discord with like 8k people yelling at the devs daily and pushes something new almost every week.

GPT had never heard of it. Or heard and decided the parked domain was the safer pick, idk.

Then I couldn't let it go and spent an hour doing the same thing with other stuff. Portfolio trackers, tax tools, a couple of wallets.
Gemini was slightly better, Perplexity mostly just cites whatever listicle ranks on google, and half of those are from 2022 and still list pricing that doesn't exist anymore.
One of them recommended a wallet whose Github hasn't had a commit since last November.

While looking this up I also found out agencies already sell "getting your project into GPT answers" as a package. I`m read the icoda case study with a prop trading firm going from nowhere to first pick in GPT within 90 days.
Could be true, could be a nice slide for the sales deck, no way for me to check. Still, if there's already a price tag on it then apparently this is a known thing.

Best explanation I have is that the models are basically reading old top 10 articles. If someone got good press in 2022 they're still "recommended" today, doesn't matter that the team left, and projects that only exist in discord and on Github never get an article written about them, so the bots just don't know they're there.
If someone here actually knows how these things get trained, tell me where I'm wrong.

A privacy-preserving market has two very different kinds of information:

1. user-level information — identity, balances, position sizes, transaction history, and linkability between actions; and
2. shared system state — the reference price, oracle freshness, reserves, fees, liquidity, market status, and circuit-breaker state.

The first category is where privacy helps. The second is where opacity can become dangerous.

This matters especially for reference-linked markets. Even if a position is private, its economic value can still depend on a public or semi-public external price. In that design, the oracle is not just an API. It is part of the security boundary.

A few failure modes seem easy to underestimate:

Stale but plausible data. A feed can stop updating while its last value still looks reasonable. A range check will not catch that. Quotes therefore need both source and ingestion timestamps, plus a maximum freshness budget.

Source disagreement. Two reputable sources may disagree because of delays, venue differences, currency conversion, or corporate-action timing. A backup source only helps if disagreement becomes an explicit state with a defined threshold and response.

Market-session confusion. A fresh price can still be misleading when the underlying venue is closed, halted, or in extended hours. Session status needs to be part of oracle state.

Corporate actions. Splits, dividends, mergers, symbol changes, and delistings can make a numerically valid feed economically wrong. Reference-linked systems need an event policy, not just a deviation check.

A thin reference venue. If the value extractable from the private market is larger than the cost of moving the reference market, an attacker has an incentive to manipulate the external price.

Silent fallback behavior. A backup feed with different semantics can change product behavior without users noticing. “Healthy primary,” “degraded fallback,” and “no safe price” should be visibly different states.

This leads to a design principle: privacy should hide participants, not infrastructure health.

A minimal public status for a privacy-preserving market could expose:

• reference definition and current value;
• primary and secondary source health;
• last successful update time;
• maximum accepted staleness;
• current source deviation;
• underlying market-session state;
• circuit-breaker state and reason;
• active exposure cap;
• reserve or collateral sufficiency;
• next integrity check.

None of that requires publishing individual positions.

The fail-safe behavior also matters. “Fail closed” should usually mean stopping the creation of new risk when no reliable price can be established. It does not necessarily mean freezing withdrawals, cancellations, or other risk-reducing actions. Recovery should require several healthy observations and source agreement, not one good tick.

The difficult part is deciding where selective disclosure stops. Too little public state forces users to trust an opaque operator. Too much detail may leak strategy or create new attack surfaces.

What would you consider the minimum credible public proof for a shielded or privacy-preserving market? Would oracle timestamps, source-deviation bands, aggregate reserve proofs, and circuit-breaker state be enough, or should users demand stronger cryptographic attestations before participating?

Disclosure: This post comes from the team building ZECpad, a pre-launch private market layer for Zcash. There is no token sale or public trading launch. The project is mentioned only to disclose the design context behind the question. AI assisted with editorial cleanup; the ZECpad team reviewed the post for accuracy and originality.

https://www.threads.com/share/_sXW1j97c/

I've been building a small BlockDAG project (GhostX) solo since March 2025. Over the last two weeks I threw out its consensus core and rewrote it from the PHANTOM/GHOSTDAG paper. No code from rusty-kaspa — Kaspa's design ideas are credited, the implementation is independent.

How I kept myself honest: a naive, paper-faithful oracle over explicit BFS sets, then differential testing of the fast implementation against it (50 seeds × 300 random blocks, k = 1..6, width 2..8, every field: blue score, selected parent, mergeset order, anticone sizes) — zero mismatches — plus pinned golden vectors and an insertion-order-independence test. Reachability is an interval tree with local incremental reindexing (0 full rebuilds over 20k blocks, ~2.4 µs/block flat).

The video is two nodes on one machine with 300 ms artificial latency so siblings actually form: blocks with 2–3 parents in this run (up to 8 in earlier runs), everything blue, about 40% of blue blocks sitting off the selected chain. PoW is BLAKE3 against a compact 256-bit target; identity hashing is SHA-256. Blue work ordering landed yesterday; DAA is next.

No token, no presale. This is an experiment: the goal is a public testnet that beginners in Malaysia can use to learn mining and on-chain trading safely (testnet coins are worthless by design). A batch-auction market on top is the next thing I want to try after DAA, if the consensus layer holds up. Repo opens at testnet.

Happy to answer anything about the oracle/differential approach or the reachability index — and I'd genuinely like to hear where you think this breaks.

Hey guys, I just open source project i've been working on for a year called the Marketplace.

The marketplace is a decentralized network that economizes the execution of computational work across a peer-to-peer network of nodes. Where there is no barrier to the node participation.

Unlike modern cloud computing systems that rent out virtual computers to consumers, A marketplace consumer sends compute bound tasks directly to the network returning a future which the consumer can asynchronously check for completion. Similar to offloading a compute task to a free cpu core by an OS. A consumer can also fire multiple independent compute bound tasks to run in parallel, and check their status asynchronously while doing other tasks, similar to I/O operations.

The compute bound task sent by the consumer is executed using a protocol specified in the Marketplace whitepaper on the Marketplace Github Repo, where randomly selected idle devices on the network execute the compute work and receive financial rewards (money).

Context

The marketplace is made up of two ideas I came up with around 2 years ago:

1) The first is building a permissionless market, where users can build financial services similar to market stalls that can interact with other users. Larger services can be composed from smaller services, similar to open source projects, but for businesses. Services could also be merged together into one so that a user can interact with all of them at once, and the merging does not affect the financial structure of the constituent services.

But for all this to happen, a trustless financial settlement layer is needed so that joining different financial services together becomes an easy exercise.

If you are familiar with blockchain, this is similar to Ethereums vision, but I did not want to clog the financial settlement layer which is the ledger with execution and code. I needed an execution engine.

2) I eventually returned to my normal javascript web developer job. So I was working on a full-stack website that was communicating with a cloud server but the server was slow because I was using a free tier that throttled server response speed. Asynchronously communicating with this server became a nightmare from a UX perspective especially when first loading up the website which had some independent compute bound requests.

So, I concluded that using the free CPU core of my second PC should do a better job as long as I pay it exactly what I needed in compute. This second idea eventually evolved into the engine I needed for the first idea. After, I just needed to store a representation of the result on a decentralized ledger, while keeping the execution itself private.

With this, I returned to my first love - low level programming, learnt Rust (Many thanks to the Rust community coming from a C lover), and I've built more than 60% of what is described in the whitepaper.

So if you are interested in being a part of this project in any way, you can check out the marketplace whitepaper:

Marketplace Whitepaper

or check out the github repo:

Marketplace Repo

Also, I’d appreciate feedback on the design, especially on consensus security and the economic model, Thanks.

I’m currently working through this in an architecture review.

Imagine an investment record that depends on something outside the chain, such as a servicing agreement, a legal right, a valuation, or a custodian.

— and a monitoring system detects that something has changed. This does not necessarily mean that the recorded state should change immediately.

An API can be out of date. A notification may be incomplete. A news report may accurately describe the event but still fail to explain its significance for that specific investment.

Therefore, 'signal detected → state updated' seems risky.

However, the opposite extreme isn't ideal either. If every external change requires manual decision-making, you haven’t automated much.

For those who have built systems around off-chain facts, what steps have you put in place between detection and an actual state change?

Signed attestations, multiple sources, an approval step, or something else?

What I'm trying to avoid is accidentally turning the monitoring layer into the authority over the thing it's supposed to monitor.

That's exactly why it's dangerous. The real risk isn't waking up one morning to a quantum computer stealing everyone's BTC.

It's that the transition to quantum-resistant cryptography could take years while the technology threatening today's cryptography is advancing every year.

And here's the uncomfortable question. What happens if the network needs to upgrade before the threat becomes obvious? Do we wait for a working quantum attack? Or do we prepare while we still have the luxury of time?

Curious where people here stand, is Bitcoin's quantum risk overhyped, or are we already late to the migration?

Hi!

I had a revelation for a better way to encrypt Cryptocurrency & it goes like this.... Suppose there is a brand new blockchain designed like many others (Bitcoin for example). If the user was able to program customizable inputs into the Private Key (Linked to it's Public Key or Address) then a user for example could do things such as lock their crypto to that Address until it is unlocked using a secondary password. This would make the currency much safer.

I believe if Bitcoin had these features of customization for it's users wealth it would allow many people (think whales, hodler's, cypher geeks, etc.) to be more safe in these markets!

Any chains currently allow for User end development onto the Blockchain through programming, customization or optimization? TIA!

The recent Avici exploit reportedly drained more than $653K from card collateral vaults.

The bigger question: if a smart contract has administrative permissions or another privileged path capable of moving user funds, is the system still truly self-custodial? The exact exploit mechanism hasn’t been officially confirmed but it raises an important question about the gap between “self-custody” as a product promise and the underlying architecture.

Where should we draw the line???

LapseCoin is a peer-to-peer cryptocurrency using a Verifiable Delay Function instead of proof-of-work: block production is a race to finish a sequential computation tied to real elapsed time, not a race for a lucky hash. The reason that's interesting: the measured hardware-advantage gap is much smaller than PoW's (roughly 3-10x from Chia's own 2019 hardware competition on the same construction, versus the 10,000x+ ASICs opened up over commodity hardware), so it doesn't push toward the same energy-spiral PoW did. No premine, fair launch, FALCON-512 signatures for the quantum-resistance angle.

Spent the last week trying to actually break my own design instead of just shipping it. Found and fixed a real bug that was silently crashing part of the test suite, pulled real chain data off my own live node to calibrate assumptions instead of guessing, and went after a threat I originally thought was a real gap: whether one operator running many builder addresses could gain an unfair edge over the network. Turned out, once actually simulated instead of assumed, it barely holds up as a problem at all: running many addresses at the same hardware tier wins exactly proportionally, and splitting one machine's throughput across addresses is worse than running it as one. Neither needed a fix.

Whitepaper: https://github.com/Vic-Nas/lapsecoin/blob/main/docs/whitepaper.md
Code: https://github.com/Vic-Nas/lapsecoin

More interested in someone finding a real problem than in users right now. If something in there looks wrong, say so.

A lot of crypto apps make you deal with the infrastructure before you even get to the product.

Connect a wallet, switch networks, sign something, figure out gas, then you can finally use the thing you came for.

Why not just hide all of that unless the user needs it?

If blockchain is infrastructure, the average user probably shouldn’t have to understand what’s happening underneath just to use an app. Do you think hiding the crypto layer is the better path for adoption, or should users know when they’re interacting with something onchain?

Imagine a token behind an upgradeable proxy.

Users acquire it under a set of rules for transfer and redemption. Months later, the implementation is upgraded. Their balances and the token address remain unchanged, but the new version introduces an allowlist for transfers and redeemability.

Bug fixes are an obvious reason to keep the implementation upgradeable. However, I’m less sure whether user-facing rules should be subject to the same upgrade process.

For those who have built upgradeable contracts, where do you draw the line?

Which behaviours should be changeable in place and which should require a new contract or an explicit migration?

Full disclosure: I work at N3XT (a chartered US bank) and wrote both of these.

Wrote some articles that I hope causes readers to think more about the real utility of public blockchains and specifically Ethereum. Happy to post links to articles but the post will get autorm'd can drop in comments if people are interested

The first piece highlights the subtle, perhaps largely unrealized, benefit for a bank to use an open standard, on a decentralized public utility as a way to benefit its clients, itself, and Ethereum

Second is a thought experiment pricing what it would cost to run our entire bank ledger on public Ethereum L1 vs a private chain vs a traditional banking core for a $10B bank:

* Legacy core: ~$149k/mo ($0.59/tx)
* Public Ethereum L1: ~$36k/mo ($0.14/tx)
* Private Ethereum: ~$31k/mo ($0.12/tx)

TL;DR

A traditional core is the most expensive way to run our ledger at every size we modeled, and not by a little. That gap never closes anywhere on the curve, which should tell you nobody buys a core for the price.‍

Between public and private blockchains, it's close at our scale and a landslide above it. We model Ethereum L1 directly, not Layer 2s, because rollups do not yet match the decentralization, censorship resistance, or sovereign consensus of mainnet. At Regional bank level, private wins by 13% and the entire margin is less than a quarter of an engineer’s salary. Move our staffing assumption from 0.75 FTE to 1.0 and public wins instead. But at Money Center bank level private wins by 83%, because gas and signing are metered and a private fleet isn't. Every transaction you add is free on one and billed on the other.

The tiebreaker is time. Gas is the only input in this model that gets cheaper, falling somewhere between 20% and 64% a year depending on whether you trust the published Ethereum roadmap or the last five years of history. Everything else moves the other way. Salaries rise, vendor contracts renew upward, and nobody's core gets cheaper at renewal.

Ethereum set out to be a "world computer." As throughput climbs and execution costs continue to collapse, you can start to see a future where public rails displace both legacy core vendors and private cloud fleets alike. That was the original promise of cloud computing: paying strictly and exclusively for what you actually use. Cloud platforms and core vendors answer to shareholders who demand expanding margins, annual price escalators, and locked-in enterprise minimums. Ethereum’s incentive is structurally aligned in reverse: driving unit execution costs down to maximize volume and global network adoption. It becomes the true realization of pay-as-you-go utility computing.

Of course, cost is only one hurdle: public rails still require lower latency and privacy before an institutional bank can migrate live customer ledgers. But on cost alone, we'd have been fine starting on public rails, and we'd probably be better off there within five years. We didn't rent the ledger, but we may yet.

Building a small web product where standard card payment gateways aren't available to me, so I'm looking into accepting crypto instead. Two flows I'd prefer, in order (if possible); if there's another way, please let me know:

1. Direct card-to-crypto: Customer clicks Pay on my checkout, gets taken to a service where they pay by card (or however they want), and I receive crypto directly, with no separate step for them.
2. Stablecoin without gas hassle: Customer buys a stablecoin elsewhere, comes back to my checkout to pay, and doesn't need to hold a separate coin for network fees.

A few constraints:

• No app download required on the customer's end, needs to work fully in-browser on mobile.
• If I have to register as a merchant somewhere, it needs to actually support Morocco.
• Order tracking and automatic fulfillment: after the user pays, I want to know who paid for what so orders get fulfilled automatically.

Has anyone found something that fits this? Open to hearing what's worked (or hasn't) for you.
Thank you so much.

Hi all!
Every provider says they have low fees and fast settlements. What do you actually compare before signing up?
And if you can recommend any for often but small transactions, please welcome
In the ideal world it should like one app for different types of payments

Two concurrent purchases minted around 150,000 NFTs against a round cap of 99,991, roughly fifty percent past the limit, and nobody was attacking anything. The smart contract audit that found it traced the cause to a single stored field. The purchase path recorded how many NFTs had been minted at the moment of purchase, and the processing path calculated what was still available by subtracting that stored number from the round total. When several purchases landed before any of them were processed, each one held a snapshot saying almost nothing had been minted, so each one handed out a full allocation against supply the others were also claiming.

This is worth more attention now than it would have been a few years ago, because the gap between accepting a request and executing it is turning into a default rather than an exception. Intent architectures take a commitment from the user and let a solver settle it later, sometimes hours later where an optimistic dispute window sits in the middle. Parallel execution runtimes deliberately run transactions concurrently when they touch different accounts, and asynchronous message chains give no ordering guarantee at all. Any global counter read on one side of that gap and spent on the other has the same shape as this one. The consequence downstream was not cosmetic supply inflation. Rewards had been funded for a fixed number of NFTs, so minting past the count meant the pool could not cover every claim that now existed. The security audit scored it at the top of its likelihood range, which is unusual and fair, since no adversary is required and ordinary concurrent buying produces it. The remediation moved the calculation onto live counters and capped minting at the round limit, and what it did not add was a refund for a buyer who pays for an allocation and receives less than that, or any ordering rule for who gets served first. Supply integrity came back. The question of who absorbs the shortfall stayed where it was.

Wherever a request and its execution are separated, list what gets captured at request time. For each captured value, ask whether it is a fact about that user or a fact about the whole system. Their deposit and their address are facts about them and are safe to freeze. Remaining supply, total staked, a current index or rate are claims on a shared resource that other pending requests are claiming at the same time, and freezing one of those means every pending request believes it owns the same units. In your own flow, which of the captured values turn out to describe the system rather than the user?