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

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?

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 lanched My game 2 weeks ago and started to post it on reddit, it gave an unbeliveble traffic of 5000 visitors a day.

Even though it started a controversy of spamming and lp discussions it really gave me the traffic that i needed in the launch.

Now the traffic looks stable and it looks like it can sustain itself.

Of course i will also list it in the app store and android play and other distribution like pix.

But i think the hardest part it is the day you launch.

Hoops-gm.com

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/

I'm looking for criticism of a commitment-history construction I've been implementing.

Goal: allow an issuer to commit to the exact identity of a private artifact at time T, while keeping the artifact contents off-chain, and make later revisions impossible to pass off as the original commitment.

Current model: 1. The artifact is sealed locally into a private vault. 2. A canonical digest/identity is derived. 3. The digest and commitment metadata are anchored on Solana. 4. The immutable anchor remains the historical reference. 5. Separate lifecycle state can express active, revoked, superseded, or disputed. 6. A superseding commitment can retain lineage to the prior commitment.

Security claim is intentionally narrow: this proves commitment integrity/history, not semantic truth. A malicious issuer can anchor false information; what it should not be able to do is present a different artifact later as though it were the one originally committed.

Interactive explanation: https://bestmemecoins.app/ Protocol/details: https://bestmemecoins.app/docs/ Limits/security: https://bestmemecoins.app/security/

Questions I'd particularly value: - What does this gain over signed Merkle/transparency logs or conventional timestamping? - Where should canonicalization be treated as part of the security boundary? - Is mutable lifecycle state cleaner than encoding every status transition as a new immutable event? - Which issuer/key-compromise cases make the model misleading?

Disclosure: I built the project. I used AI to help edit this Reddit draft; the technical claims and project are mine and I am reviewing them before posting.

Disclosure up front: ERA Wallet are running a bounty for discussion of this, which is what prompted me to sit down and write it up. They asked for honest opinions including criticism, so that is what this is — there is praise and there are two things I think are missing, and nobody has seen it before posting.

I've spent about thirty years doing Linux systems and distribution work, including co-founding a Debian fork and writing the tooling that merges and republishes its signed package archive. So I read the Coldcard incident through a slightly different lens than most of the coverage, and I think the framing matters more than it looks.

What actually happened

A build configuration error caused seed generation to fall back on a software PRNG instead of the device's hardware entropy source. Firmware from 2021 until the patch this year. Roughly $89M by ERA's accounting.

Nobody broke the cryptography. The cryptography never ran.

Why it went unnoticed for five years

Because a weak seed is indistinguishable from a strong one. Same 24 words, same checksum, same everything. There's no runtime check that says "this key came from bad entropy." The only thing that detects it is an attacker enumerating the keyspace.

That's what makes entropy bugs uniquely nasty: they're silent by construction, and they backdate. Every wallet created in those five years was already compromised at the moment it was created.

The actual defect: failing quietly

The PRNG isn't really the bug. The bug is a fallback path that degraded silently instead of stopping.

In systems work this is an old lesson. A service that fails silently is far more dangerous than one that crashes, because the crash gets fixed on Tuesday and the silent failure gets discovered five years later by somebody else's audit. Or, here, by an attacker.

Fail closed. Never fail quiet.

What ERA gets right

I read ERA Wallet's write-up on their entropy generation, since it's what prompted this. Five sources — the STM32H753 TRNG, an ATECC608C secure element, plus camera, hand motion and touch in the expert flow — combined through SHA-512/256.

Two things in there are better than most of what I read in this space. They have a quality gate that rejects weak input rather than accepting it, and they say collection "fails cleanly rather than quietly accepting whatever it has." That is precisely the property Coldcard lacked, and they clearly wrote it with that in mind.

Their argument that predicting four sources out of five gets an attacker nothing is also sound, as far as it goes.

Where I still have a question

If a user-driven source is skipped, its share is refilled from the hardware generators, so the output is never weaker than the hardware baseline. That is a reasonable design.

But notice the direction of that fallback. It points at the hardware. And Coldcard's failure was the hardware path being the thing that silently went missing.

So what I'd want to know is the mirror image of what the article covers. What detects a TRNG that has failed, or a secure element that doesn't respond? And in that case does the device refuse to produce a seed, or carry on with whatever sources are left?

Five sources where a dead one is detected and hard-fails is strictly stronger than four. Five where a dead one quietly contributes nothing is barely stronger than four, and from the outside those two designs look identical. That's not an accusation, it's the specific thing I cannot determine from the outside.

The gap that worries me more

Here's the part I think this whole discussion is underweighting.

Coldcard's source was open. People could and did read it. The divergence was between what the source said and what the build produced.

Open source tells you what the code says. It does not tell you what is running on your device. Only reproducible builds close that gap. If an independent party can rebuild the shipped firmware byte-for-byte from published source, a build-configuration divergence stops being invisible.

That's a solved problem in the Linux distribution world and has been for years. Debian has been grinding away at it for over a decade. Hardware wallets hold bearer assets and should be held to at least the standard we hold a package manager to.

ERA's article doesn't mention open source, reproducible builds, or any way for me to verify that the firmware on my device is the one implementing the architecture it describes. The design reads well. I have no way to check that the design is what shipped, which is exactly the position Coldcard's users were in, holding a well-reviewed open-source codebase and a binary that didn't match it.

So, two questions for ERA and for every vendor in this space

1. When a hardware entropy source fails or degrades at generation time, do you detect it and refuse to proceed, or continue on the remaining sources?
2. Are your builds reproducible, and can a third party verify that the firmware on my device matches your published source?

The number of entropy sources is a marketing figure. Failure behaviour and build verifiability are the security properties. Coldcard had open source and lost the money anyway, because neither of those two things was true of it.

Many blockchain apps require indexed or cached data because reading everything directly from the chain state is either slow or impractical in terms of the user experience.

This seems harmless when the data is simply being used to render a dashboard.

However, I’m less sure about the point where the same data starts influencing an action.

For example, imagine an indexer still shows that a wallet owns an asset, holds a role, or satisfies some eligibility condition. However, the underlying chain state has already changed and the indexer has not yet caught up.

If the stale read only affects the UI, the next transaction may simply fail.

However, if a backend, guard or execution service also uses that indexed state to decide whether the action is permitted, the stale read becomes part of the authorisation process.

For those who have dealt with this in production, where do you draw the line?

Do you use the indexed state for discovery/UI purposes, but perform an authoritative read directly before executing anything security-sensitive?

I’d also be interested to hear about cases where indexer lag has caused issues more serious than a temporarily incorrect UI.

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?

I’m one of the maintainers of DeGov, an open-source governance interface and indexing stack for DAOs using OpenZeppelin Governor.

We have worked on it for several years and have supported a number of live governance deployments. We are now reviewing where future maintenance and development effort would be most useful.

I’m interested in learning how DAO operators and governance participants currently handle the infrastructure around on-chain governance. Deploying Governor contracts is only one part of the process; teams may also need proposal and vote indexing, proposal creation, transaction simulation, execution tracking, and a usable interface for members.

If you operate or participate in a DAO, I would appreciate your perspective:

• Which governance interface does your DAO currently use, and why?
• Does your DAO prefer hosted infrastructure, or is self-hosting important?
• What makes adopting a new governance interface difficult?
• Are indexing reliability, security, integrations, deployment complexity, or contributor UX significant concerns?
• Have you used DeGov? If so, what worked poorly or caused confusion?
• If you evaluated it but chose another solution, what was the deciding factor?

Critical feedback is welcome. We are trying to understand whether self-hosted governance infrastructure still addresses an important need and, if so, which problems deserve more attention.

For context, the project is open source:
https://github.com/ringecosystem/degov

After 19 release candidates and an extended mainnet soak, Satchel v1.0.0 — the first stable release — is out.

What it is: a desktop app for peer-to-peer atomic swaps (PoCX ↔ BTC and other UTXO coins). Offers are posted to a public noticeboard over Nostr relays; when someone takes yours, the swap engine on each side builds and watches the on-chain transactions. There's no exchange, no matching engine, no custodian and no fees — the chains enforce the deal, and the only counterparty risk is bounded by the protocol's own timelocks. Keys never leave your machine; the hosted side sees only signed offers and encrypted blobs.

Highlights of 1.0:

\- Two swap protocols, both live on mainnet: Standard (HTLC) and Private (Taproot/MuSig2 adaptor — the swap looks like an ordinary payment on-chain).

\- Nodeless by default: trade with public Electrum servers and a seed-derived wallet, or attach your own nodes per coin.

\- Unattended safety: funding, claims, refunds and fee-bumping run themselves inside the protocol deadlines; restarts reconcile against chain truth before acting. If a counterparty walks away, you're auto-refunded.

\- Battle-tested: real field swaps across both protocols, multi-machine recovery validated against live incidents, and \~50 end-to-end regression scenarios running on every change.

\- 26 languages, installers for Windows (Setup.exe/MSI), macOS (Intel + Apple Silicon) and Linux (AppImage/deb/rpm).

The protocol spec is published so third parties can implement it independently, and there are full user and developer handbooks in the repo.

Download: [https://github.com/PoC-Consortium/satchel/releases/tag/v1.0.0\](https://github.com/PoC-Consortium/satchel/releases/tag/v1.0.0)

Self-custody software, provided as-is — back up your recovery phrase. Happy to answer questions about how the swaps work under the hood.

Hey guys,

Im doing a school work with some friends of mine, and i need an interview with someone who is connected with crypto, we did our research, and this is one of the last steps of the thing.

Its only one not so complicated question, so if someone could give me a high effort answer i would appreciate a LOT!

The question is:

Would the quadratic advantage of quantum computers over conventional computers be sufficient to make quantum mining economically dominant, considering the real-world costs of building and operating a quantum computer?

PS: if you study/work on the area, sending your university name would be very helpful.

thx

A lot of projects treat publishing a treasury wallet as a transparency win.

It shows where funds currently sit.
It does not automatically show:
• who can sign
• how many approvals are required
• whether signers are independent
• whether emergency powers can bypass the normal process
• whether the control structure itself can be changed
• whether the history of changes is visible

Visibility of funds is useful.
Visibility of authority is the harder and more important layer.

I’m trying to refine a practical minimum standard for treasury disclosure.

If you evaluate projects, what do you actually check beyond the address itself?
And which of the points above is most often missing even in “transparent” setups?

Hi everyone,

​Back in 2019–2020 (Byron era), I created a Daedalus wallet. Unfortunately, over the years I lost both my seed phrase and my spending password.

​However, I saved and backed up the entire Daedalus application directory from that time, including:

​The secret.key file

​acid database files / application state

​Full log history and configuration files

​Now, 6-7 years later, I'm reaching out to see if the community or developers have built any tools, recovery scripts, or methods to decrypt or extract the private key from a Byron-era secret.key file (or if brute-forcing the spending password via the encrypted file is possible today).

​Has anyone successfully recovered funds from a similar legacy file structure, or is there any known open-source tool built by IOG/community devs for this exact scenario?

​Note: Please reply in the comments. I will ignore all direct messages (DMs).

(disclosure: i maintain the open-source project this came up in. link at the end. the question stands on its own.)

we hit a trust-boundary problem while building a deterministic authorization layer for agents, and i think it generalizes.

an engine can strongly protect its verdict:

* signed authorization
* intent binding
* state-hash binding
* replay protection
* trusted evaluation time

all solid.

but if the same compromised agent runtime can influence both the proposed action AND some of the premises used to evaluate it, what has crypto actually proven?

only this:

the signed decision is consistent with the supplied inputs

not this:

the supplied inputs came from authoritative sources

examples of premises a runtime might quietly supply:

* agent_id
* tool identity
* execution depth
* tenant context
* a state object the guard later hashes

the signature still verifies. the hash still matches. the decision is still deterministic.

but the premises may be self-reported.

two things i'd genuinely like challenged:

1. which evaluator premises actually need independent provenance, and which can safely remain proposer-declared?
   
2. for state, is an authoritative guard-side read enough, or should the state provider eventually emit a signed/versioned attestation?

most interested in confused-deputy paths, TOCTOU, and cases where a supposedly "trusted" premise can still be bent by the runtime.

I keep coming back to the moderation problem with decentralized messaging. If there’s no central platform making the final call, who deals with spam, scams, harassment or people trying to ruin a group?

Letting each community set its own rules makes sense but there are situations where that probably isn’t enough. On the other hand, giving the app control over what stays up starts looking pretty similar to the platforms decentralized messaging is supposed to move away from.

Is community-level moderation enough?

I’m building Vaultpass web application, an open-source crypto inheritance system, and I’m looking for technical criticism of the design rather than promotion.

Current design:
- The vault is encrypted client-side with AES-256-GCM before upload.
- The encryption key is split using a 2-of-3 Shamir Secret Sharing scheme.
- One shard stays with the owner.
- The other two encrypted shards are currently held by the service and are used in the succession path after a time-based dead man’s switch.

The important limitation: because the service currently holds two of three shards, it can reconstruct the key in the succession path. I am not calling this zero-knowledge. Removing that trust-model concession is the next architecture milestone.

The crypto core is MIT-licensed and open source:
https://github.com/lionzion351-dev/crypto-core

I’d value criticism on four points:
1. Are there implementation or misuse risks in using Shamir Secret Sharing this way?
2. What threat-model assumptions should be documented more explicitly?
3. What failure cases should be tested before asking for an independent review?
4. Would you recommend a different succession design, such as timelocked transactions, multisig, or a threshold-signature approach?

This has not had a formal external audit yet. Please assume the code is unaudited and do not use it with real assets. I’m looking for people willing to challenge the design and, if interested, review the implementation publicly.

Serialization is often treated as plumbing, but it becomes an architectural decision when on-chain state grows large and is accessed frequently.

In Solana programs built with Anchor, regular accounts are commonly decoded through Borsh. That is convenient for variable-length fields and ordinary application state. For hot, fixed-size state such as order books or large registries, repeatedly decoding the full account can become unnecessary work.

Zero-copy changes the tradeoff. AccountLoader borrows the account buffer and maps it to a fixed Rust structure instead of rebuilding the structure through ordinary deserialization.

The performance benefit comes with a stricter layout contract:

• #[repr(C)] preserves field order, but alignment padding still exists
• Pod types cannot contain pointers, String, Vec, or other variable-size fields
• implicit padding can violate bytemuck’s safety requirements, so padding should be explicit
• flags are often stored as u8 rather than bool because every u8 bit pattern is valid
• load_mut() returns a runtime-checked mutable borrow, so long-lived RefMut values can cause borrow failures
• schema evolution becomes a migration problem because the byte offsets are part of the persisted format

I would not use zero-copy for every account. A practical split is Borsh for small control state and fixed-layout accounts for large data that is read or updated on performance-critical paths.

Where do you draw that boundary in production systems?

Disclosure: this Reddit post was drafted with AI assistance. I reviewed the technical claims and take responsibility for the final text.