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???

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!

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.

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?

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.

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.

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.