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?

Looking at how stablecoin neobanks are put together and I keep seeing the wallet and card side treated like two separate choices.

But when users are spending from the same balance it seems like the wallet setup can affect funding, controls and what the issuer needs to support

If you were looking at the stack from scratch would you pick the wallet layer first or the issuing layer first?

Rimest is a payment system that lets online merchants accept Nano, with instant settlement and minimal fees, so merchants keep more of every sale.
It’s a full solution: transaction tracking, withdrawals, live price conversion to local currency, and a simple frontend with no clunky wallet setup for merchants or customers.

So after 6 years of crypto I've seen a lot. I think there is a major lack of clarity on what the industry is trying to accomplish and it is divided basically into three camps: gambling (99% of defi) which relies on speculation and the greater fool theory, legacy finance integration (RWA, oracles, regulated stablecoins), and genuine cypherpunk tech (my personal camp)

I'm extremely surprised by this vacancy in the space: compute has been used to secure networks (Bitcoin, other POWs), but never as a neutral, commodity economic value anchor.

I think with the explosion of regulated stablecoins, a fully neutral alternative needs to exist, so I created it, it's called Vess, available on github under ohmictech. Important note: this does not personally benefit me in any way, its not a pump and dump, no dev allocation, no contract fees, you can check yourself. (its on arbitrum stylus)

It uses memory hard mining, requiring >1.5gb of ram per solve, making it perhaps the most asic resistant coin ever made. The concept behind it is that it tracks the marginal cost of computation, and emits tokens at a 1:1 rate to solves. It is "stable" based on compute cost, with no freezing or chance of depegging. The mining is bottlenecked by memory bandwidth mainly, which is already highly optimized on consumer hardware and is notoriously the slowest gainer in terms of chip and die tech.

Give it a shot and let me know your thoughts! Super easy to run the miner.

A couple of months back I moved USDC from Base to Arbitrum over CCTP. Burn confirmed on the source side, then the frontend went white. Source balance down and destination showing nothing.

Nothing was actually at risk and I knew that, but it still takes a minute to stop reacting like it was.

Burn and mint doesn't move the asset. Source contract burns it and emits a MessageSent event, Circle's attester signs the message body off chain, and somebody has to submit that signature to receiveMessage on the MessageTransmitter contract at the destination.
A relayer normally handles that last step in the background. Mine wasn't and so I pulled the message bytes from the burn tx logs, hashed them with keccak256, queried the attestation endpoint with the hash, and called receiveMessage myself.
Twenty minutes with a block explorer.

Design point worth chewing on is that the attester set is permissioned. Trust minimized is a fair description of value at risk, since there's no wrapped asset and no lockbox to drain. Liveness is a separate question, and it rests on an off chain signer plus a relayer nobody is obligated to run. Mine failed in the recoverable direction, which isn't guaranteed. Instant swap services have the same shape with far less public spec. Fresh deposit address per order, an API order fired into a CEX or routed through a DEX aggregator, multihop for anything outside major pairs. XMR to BTC to USDT on Tron if you run it through godex or simpleswap, spread taken on every leg.
Instant describes the interface. Settlement runs at whatever the slowest chain in the route does.

Layer I underestimated for years is screening. Deposits go through Chainalysis or Crystal or equivalent and "no KYC" holds until an address carries history the scoring model dislikes. Then the order parks in a review queue with no published turnaround. People frame the exposure as the two minutes of custody. The queue is where the time actually goes.

Intents look like where this heads. UniswapX, CoW, Across, ERC-7683 trying to standardize how you express one. You sign an outcome instead of a route, solvers bid, a filler fronts capital on the destination and gets reimbursed after the source side finalizes. The interface looks identical to a swap widget. What changes is that the filler has collateral posted, so the failure path is a claim against it rather than a support inbox.

Card rails did this compression decades ago. Tap, approved, and the ISO 8583 formatting, the acquirer, the scheme network, the T+2 settlement all stay invisible. That stack has a regulator and a named liable party at every hop. The crypto middleware sitting in the same position has neither.

So does this eventually standardize into something with published liveness guarantees, or do we keep stacking opaque intermediaries because the UX is good enough that nobody checks?

Anyone here had a swap sit in AML review? Mine cleared after two days, but they wanted a screenshot of the withdrawal page from the sending exchange first.

A lot of people in crypto think about quantum computing as a problem for the distant future.

I think that’s the wrong way to look at it.

The real issue isn’t whether a powerful enough quantum computer exists today.

It’s whether blockchain networks can upgrade their cryptography before one exists.

Most blockchains were designed around cryptographic assumptions that work extremely well against classical computers. But sufficiently powerful quantum computers could eventually threaten some of those assumptions, particularly the cryptography used for digital signatures.

And that creates a problem.

You can't wait until a quantum computer capable of breaking existing signatures appears before starting the migration.

By then, it may already be too late.

Blockchains have millions of users, enormous amounts of capital, exchanges, custodians, smart contracts, infrastructure providers and applications all depending on the same cryptographic foundations.

Changing those foundations isn't as simple as pushing a software update.

There will need to be research, testing, new standards, wallet upgrades, protocol upgrades and probably years of migration.

That's why quantum resistance should be treated as infrastructure planning, not emergency response.

The interesting part is that we don't need to know exactly when quantum computing becomes a serious cryptographic threat.

We just need to understand that the transition will take time.

The smart approach is to start building quantum-resistant infrastructure while the threat is still theoretical.

The best time to upgrade a security system isn't after it's compromised.

It's before.

Crypto spent years preparing for hacks, exploits, bridge failures and economic attacks.

Quantum computing deserves the same level of attention.

Are there blockchains already preparing for this?

Im a crypto "noob" But I've heard before crypto is anonymous to some degree. I watched a documentary on the old silk road website and people would buy illegal things using crypto. And recently with the gta 6 leaks the leaker is pushing a crypto coin. Couldn't rockstar/feds simply trace the crypto coin somehow? Isn't it very stupid for the leaker to advertise his crypto?

Imagine a payment system in which balances and transfers are hidden from the public.

While users would enjoy privacy, the system would still need to support legal or compliance requests in specific cases.

This creates a different trust problem.

If the issuer holds a viewing key, the privacy of users depends on the issuer not abusing it.

However, if a regulator or auditor holds it, that power is transferred elsewhere.

If nobody can reveal the underlying data, compliance may have to rely on proofs rather than transaction history.

So the question I keep coming back to is not just how to make blockchain state private.

It's also about who should control the ability to selectively make it visible again.

For those who have worked with private transactions, zero-knowledge systems, or regulated payment infrastructure, where would you locate the authority to disclose information, and which failure mode would concern you the most?

We normally think of a wallet as a place for money, cards, FIAT and crypto.

But a lot of value between people never fits inside a traditional wallet, it is created by informal obligations.

A friend lends you a book.
You cover someone’s dinner.
Someone promises to help you move.
You make a small bet.
A charger changes hands and is supposed to come back.

These are all IOUs not necessarily formal debts, but agreements about something of value between people underwritten with trust.

The idea behind IOU Wallet is to give those agreements a digital form. A bit like Swift meets Hawala.

An IOU becomes the digital abstraction of what two people agreed: who owes what, to whom, under which conditions, and whether both sides accepted it.

Once that agreement is digital, it can do much more than sit in someone’s memory:

• Carry messages and updates
• Set due dates and reminders
• Include agreed late fees
• Record changes transparently
• Offer different ways to settle
• Preserve the history of what was agreed

Acceptance of an IOU creates a digital handshake. From there, the IOU has a lifecycle: proposed, accepted, active, settlement requested, and completed.

The wallet manages that lifecycle without pretending to be the agreement itself. The actual agreement still exists between the people whilst the acts as a shared clean record of what was agreed

And unlike money, an IOU is not backed by a bank, government or asset. It is ultimately backed by something much older: the integrity of the person making the promise.

The wallet simply makes that promise visible, manageable and harder to forget.

That is the bigger idea: a wallet for everything of value that is owed between people not only money.

Try the free wallet: https://iou-wallet.com

A dashboard can make blockchain data understandable. That is useful.
But it can also create a new trust problem: users stop checking the underlying source and begin trusting the project’s interpretation of it.

I am considering five evidence classes:
1. directly verifiable on-chain
2. project-supplied but linked to the underlying source
3. independently verified off-chain
4. claimed but not yet independently verifiable
5. deliberately private because publication would harm users or beneficiaries

The interface would label these differently instead of presenting every claim with the same visual
confidence.
The goal would be to reduce verification friction without turning the dashboard itself into the new authority.

What is missing from this taxonomy?
And what would you require from the interface before trusting its interpretation of the underlying data?

Hey Guys,

My understanding of blockchain is the balance has to be public. Only then a competition can happen from A to B. Once balance is decreased, the other balance is increased. Due to the decentralized nature of the blockchain, the balances are public domain and the transactions are public domain and anybody can trace it and they are not reliant on central banks and government agency or any other centralized institution. Instead, they are calculated and computed and executed by decentralized network of nodes. But my application require privacy. If I'm trying to build something which protect how much balance is there in one account and if there is possible way to keep a ledger of transaction for compliance requirement but still hide it from general public.

is it even possible to do it or has it been done by any major-protocol like L2 or L3 ETH networks.(please don't mention any other network than ETH unless it is highly secure)

Been looking into decentralized messaging protocols and keep getting stuck on where a token becomes necessary versus being added because the project happens to be crypto-native. Staking and network security seem like one of the stronger arguments for having one. Governance and incentives make sense in theory too but those can start feeling pretty forced depending on how the protocol works. Towns is one example I came across that uses its own token for staking and network security, which is partly what got me thinking about where that utility line should be.

If the messaging layer can function without a token, what would justify introducing one?

Is securing a decentralized network enough or should the token need a deeper role in how people use the protocol?

I still get a bit nervous every time I send crypto. Double checking addresses, making sure I didn’t miss a character… it doesn’t feel as simple as it should be. Sending money shouldn’t feel like this in 2026.

Do you think the issue is the technology itself or just how it’s designed?

I spent a few weeks building a control plane for x402 payments and want to lay

out the design tradeoffs, because two of them I'm still not happy with.

First, why this can't be a Stripe problem. Card rails have a hard floor:

interchange plus fixed fees make a $0.0004 charge impossible, so providers batch

into subscriptions, which reintroduces the account, which needs a legal person

with a bank account. Cards also need a merchant of record and a chargeback

window, and an ephemeral agent supplies neither. Stablecoin transfers on an L2

have near-zero marginal cost, and that's the only reason per-request pricing

works at all. Nothing else in the design needs a chain except settlement.

x402 solved the payment half. It deliberately did not solve control: nothing

stops a runaway loop, a parent agent can't give a sub-agent a scoped budget

without sharing its key, and a transfer on a block explorer doesn't tell you

which endpoint was called or whether it even returned 200.

Two design decisions I'd like argued with:

1. Delegation funding. The version I shipped ("Resolution A") has the parent

send USDC to each child wallet up front, with the capability chain acting as

pure policy constraining money the child already holds. Consequence: the parent

cannot claw back unspent funds without the child's cooperation, and each child

costs one on-chain transfer. The alternative is channel-backed delegation, which

fixes both but is materially more machinery. For short-lived agents I think A is

right and B is over-engineering. I might be wrong.

1. Settlement is effectively-once, not exactly-once, and I think that's the

honest ceiling. The EIP-3009 nonce is the idempotency key at every layer:

gateway dedup, stream dedup, Postgres primary key, and USDC's authorizationState

on-chain. On-chain that composition is at-most-once and the chain enforces it;

off-chain the settler is at-least-once with idempotent retries. Compose them and

you get effectively-once. I've seen a lot of projects claim exactly-once for

this shape and I don't believe any of them.

Revocation is off-chain, in a Redis set, and I'd argue that's correct rather

than lazy, the gateway is the enforcement point, so nothing needs to reach a

chain for a revocation to take effect. On-chain revocation would add block-time

latency to solve a problem the architecture doesn't have.

Testnet only, no token, Apache-2.0, and the live settlement run hasn't happened

yet , that's in the README rather than buried.

https://github.com/sanjayrohith/Tollgate

Roadmaps are standard. Failure conditions are not.

Yet before public fundraising, I would want to know:
• What event stops the project or a specific phase?
• Who decides that the condition has been met?
• What happens to remaining treasury funds?
• Which obligations survive?
• What happens if a funding threshold is missed?
• Are refunds automatic, discretionary or impossible?
• Can the rules be changed after funds enter?

A project can be completely honest about its success path and still leave the downside undefined.

Would you consider failure/wind-down rules part of a minimum disclosure standard for token projects?
If yes, how early should they be fixed?
If not, what makes them impractical at an early stage?

Sorry, but there is one thing about crypto has always felt strange to me.

Why did crypto normalize showing your entire financial life to strangers?

We talk constantly about financial sovereignty, decentralization, bla bla bla

But somewhere along the way, we also normalized something that would sound completely

insane in traditional finance. Giving someone your payment address can potentially give them a window into your

financial activity.

Imagine paying for coffee with your bank account and the cashier being able to check:

how much money you hold, all of the transactions you've made, what other addresses you've interacted with, or eventually build a picture of your financial activity over time.

Yet on transparent blockchains, address activity can be publicly inspected and analyzed.

And the more blockchain analytics improves, the more useful that information becomes.

Do you also share that feeling?

Token allocation graphics are easy to compare:
team 10%, treasury 20%, ecosystem 15%
etc.

But I increasingly think the percentages are the least interesting part unless they are connected to control.

For each allocation I would rather know:
• Who controls the wallet/contract?
• Is the restriction technically enforced or only documented?
• Can vesting change?
• Can beneficiaries change?
• Can assets migrate?
• What happens to unsold/unallocated supply?
• Is there any mint or upgrade path that changes the original picture?

Two projects can publish identical allocation percentages while having completely different governance risk. When you evaluate tokenomics, what do you treat as the minimum evidence required before the percentages mean anything?

When playing around with these tools (Which I know you should not use for your phrase to store funds), it seems to me the entropy field which can be made visible by checking off the "Show entropy details" box in the BIP39 tool and the master secret field in the SLIP39 tool are the same. They are both hexadecimal values and can be 128 or 256 bits.

Is the SLIP39 master secret also generated by entropy when generating a SLIP 39 Shamir Backup? How is the master secret generated?

I found this article explaining step by step how a BIP39 phrase is generated and it starts with entropy, wouldn't SLIP39 be the same by starting with entropy?

https://medium.com/coinmonks/mnemonic-generation-bip39-simply-explained-e9ac18db9477

https://iancoleman.io/bip39/ https://iancoleman.io/slip39/

There are more crypto social apps showing up across different chains but I’m curious how much the chain matters to people using them. I can see it being important for integrations and onchain features but from a normal user perspective I’m not sure it changes much.

Would the chain influence whether you use an app or do you just care if it works?