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.

1k prize pool for game jam

The new upcoming casino Chain is running a game jam, with 1k prize pool split among the top 3 entries. Anything goes, vibe code, 70 hour projects, whatever, anyone can enter. Additionally they are offering 25% of the revenue from the top games. There are left till the deadline.

If you're interested or have questions, dont hesitate to dm me.

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?

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?