I’ve been playing around with MCP integrations and the payment side is where I keep getting stuck.

I’m comfortable with an agent being able to request a purchase, but I don’t love the idea of the same model deciding what it can spend and then executing the payment on its own. That feels like too much authority sitting in one place.

The setup that makes the most sense to me is keeping approval separate: the agent submits the purchase details, the user approves it, then a single-use payment method is created for that exact transaction.

For anyone building MCP payment flows already, where are you drawing the line? Do you require approval for every payment, use spending limits, issue one-time cards, or something else?

Pump says 90% of its bridge trades landed before a typical Relay trade in its testing. Are they timing until the funds reach the destination chain, or until the actual token buy has filled? Because if you're comparing trading apps, I'd care about the whole thing from clicking buy to actually receiving the tokens. Failed attempts probably need to count too.

Anyone seen a proper methodology breakdown?

I've spent 22 years working in infrastructure and operations, and now run local AI workloads for production apps and creative projects. That background led me to a question about Bitcoin: how much of its resilience depends on being able to replace the machines securing it?

I developed this into a working paper, The Silicon Allocation Thesis. The idea is that AI demand could affect Bitcoin through competition for industrial resources: qualified fabrication capacity, chip-design teams and investment.

Bitcoin ASICs don't become AI accelerators. The possible competition is upstream, where some of the resources needed to produce different chips overlap. That overlap needs to be demonstrated for the specific process and production period; an AI memory shortage doesn't automatically mean a Bitcoin ASIC shortage.

The distinction I focus on is current hashrate versus the ability of independent miners to replenish it. A network could have substantial hashing capacity today while replacement equipment becomes harder to obtain or a future ASIC generation becomes less attractive to fund. Difficulty adjustment helps with block timing, but it cannot manufacture replacement hardware.

Whether that creates a security problem depends on who retains access. An outside attacker buying equipment may face the same shortage. An actor already holding hardware could benefit if independent miners struggle to replace lost capacity. Those are different threat scenarios.

There are also good reasons the effect might be small or go the other way. Foundries can expand. Contracts can protect supply. Older machines can remain competitive longer, helping existing miners. Slower hardware innovation alone doesn't prove weaker security.

The general concern has been raised before; the paper credits that prior work. My contribution is an attempt to connect allocation, hardware renewal and recovery in one framework, and spell out what evidence would support or contradict it. I haven't established that AI is currently reducing Bitcoin's security.

What would you measure to test this? Would procurement lead times and the time needed for independent operators to replace lost capacity tell us something that aggregate hashrate misses?

Full paper: https://paper.facundobarrera.me/silicon-allocation-thesis/

Archived version on Zenodo: https://doi.org/10.5281/zenodo.23557269

Disclosure: I'm the author. This is a theoretical working paper, not peer reviewed.

I've been exploring an architectural question around real-world asset tokenisation: can zero-knowledge proofs meaningfully reduce trust in asset verification, or do they simply move the trust assumption to whoever generates the original data?

For example, a protocol could use ZK proofs to verify that an asset meets predefined conditions without exposing confidential ownership records, valuation data, or custody information. However, if the underlying claims originate from a compromised attestor, the proof might be mathematically valid while the real-world information is still false.

Would you separate the system into an attestation layer, a cryptographic verification layer, and an independent dispute-resolution mechanism? Or is there a better way to minimise reliance on trusted data providers?

I'm particularly interested in whether combining ZK proofs with threshold signatures, slashing mechanisms, and verifiable credential systems actually improves security or merely creates more complex failure points.

For those designing production-grade RWA infrastructure, which trust assumptions would you eliminate cryptographically, and which would you explicitly accept as unavoidable?

Which one would be really more rational in terms of expected value?

I mean like "Liquidation failure" is protected, but "Market price movements" of the collateral aren't on their provider's website, I just don't get where is a difference.

Did anyone try this and run into a liqudation failure? If so how was it classified and why?

ing up treasury management for a small DAO and every comparison I find is written by someone selling one of the two. Unsurprisingly, they all conclude their own approach is better.

Here's where I've got to on my own. Multisig lives onchain so the rules are public and anyone can verify the threshold. The downsides are chain specific implementations, higher costs, and a setup that's visible to everyone. MPC splits a key into shares, so the chain only sees a normal signature. That makes it cheaper, portable across chains and more private. The catch is that you're trusting an implementation you probably can't audit, and share management happens entirely off chain

Recovery is the part I don't understand well. Rotating a multisig signer seems clear. Rotating MPC shares feels like a black box

Is anyone running either for real funds, and what made you pick one? Is anyone running both for different jobs, say MPC for daily operations and multisig for the treasury?

I'm building Finalis, a BFT blockchain in C++20 (open source, testnet only, no token sale). I wanted to share a bug that I think is relevant to anyone using VRFs or Ed25519 point checks in consensus code.

**The setup.** Each block's leader publishes a VRF proof, and its output feeds the chain's randomness. My VRF hashed to the curve with a try-and-increment loop that accepted the first candidate for which libsodium's crypto_core_ed25519_is_valid_point() returned true.

**What the fuzzer found.** The ClusterFuzzLite job (Ubuntu 20.04 image) crashed on startup: a proof my test fixture had just created was rejected. Isolating it: the same key and input gave a *different proof* on Ubuntu 20.04 (libsodium 1.0.18-1) than on Ubuntu 24.04 (1.0.18-1ubuntu0.24.04.1), and each rejected the other's. Both report version 1.0.18, but the point-validation behavior differs between the two packages. In a live network, that's a chain split waiting to happen.

**The fix.** I switched to the standard RFC 9381 ECVRF-EDWARDS25519-SHA512-TAI. Its hash-to-curve multiplies by the cofactor instead of asking "is this point valid?". I decode points and verify proofs with plain big-integer arithmetic, so libsodium's validation never decides the result. Proving still uses libsodium's constant-time code for the secret scalars. Every node checks the three RFC test vectors at startup and refuses to run if it can't reproduce them. Since validators had to agree on new outputs, I reset the testnet instead of shipping it.

**Lessons I took from it:**

- Don't let a library's "is valid" check define consensus behavior unless its exact semantics are pinned.

- The same version string doesn't mean the same behavior. Distro security backports change code without changing the version.

- Run fuzzers and tests on more than one OS image. Mine only caught this because CI used an older base image.

Happy to answer questions, and I'd welcome criticism of the approach. Code: github.com/FinalisCore/finalis-core (src/crypto/vrf.cpp)

I'm researching embedded wallet infrastructure (and full disclosure: my team is exploring building in this space, so I want to understand what actually hurts before we build anything).

If you've used Turnkey, Privy, or Web3Auth (now MetaMask Embedded Wallets) in production, I'd love to hear:

1. Why did you pick it over the others? Pricing, security model, time to integrate, chain support?

2. How long did integration actually take, and what was the hardest part? (Turnkey folks: did setting up your own Google/X OAuth apps or writing policies slow you down?)

3. What broke or surprised you after launch? Recovery, key export, billing jumps, rate limits, support response?

4. Have you considered switching? What's keeping you, or pushing you away?

5. If you could design the ideal wallet SDK, what would it do that none of these do today?

Not selling anything here. Happy to share back a summary of the responses plus the comparison notes I've put together (pricing, architecture, who uses what) if people are interested.

On most chains a transaction is broadcast in full and sits in a public mempool until it's mined, which is what makes mempool front-running and sandwiching possible. Midstate, a small post-quantum PoW chain, makes every spend a two-phase commit-reveal at the consensus level instead. I'd like to hear where people think this falls short.

How it works

1. Commit. The wallet builds the full transaction, then broadcasts only a 32-byte BLAKE3 hash over a network tag, the input coin IDs, the output hashes and a random 32-byte salt, plus a 64-bit nonce. The commit pays no fee. Instead the nonce needs at least 24 leading zero bits of proof of work, tied to a block hash no more than 1,000 blocks back. The mempool raises that toward 30 bits as its commit lane (capped at 1,000) fills up.
2. Wait. The wallet waits until the commitment is in chain state, not just the mempool, and adds a random delay before revealing (5 to 15 seconds, or 30 to 120 with a privacy option) so timing alone pairs commits and reveals less easily.
3. Reveal. The full transaction (inputs, outputs, salt, signatures, fee) goes out. Nodes recompute the hash and reject it unless a matching commitment is on chain and less than 1,000 blocks old. The signatures sign the commitment itself, so nobody can swap the outputs.

Miners are paid to include zero-fee commits through fork-choice weight: each commit adds 2²⁴ to the chain weight, capped at a quarter of the block's own work. Each block can carry up to 2,000 commits and 500 reveals.

Known limits

• The reveal is public, and miners still order reveals inside a block.
• A commit and its reveal can share a block, so a miner who also trades could in principle act on a reveal straight away.
• Commits don't lock coins. For shared coins, like an open covenant order anyone may fill, the first valid reveal mined wins.
• It hides contents, not activity or timing.

Questions for the sub

• Is paying for commits with capped fork-choice weight sound, or is there a cheap way to game it?
• For shared-coin cases like on-chain limit orders, is there a better defence against a miner reordering reveals?
• Is per-transaction commit-reveal worth at least one extra block of latency, compared with encrypted mempools or threshold-decryption schemes?

Code: https://github.com/ciphernom/midstate (see src/core/types.rs, src/core/transaction.rs and src/mempool.rs)

Disclosure: I'm involved with the Midstate project, and I wrote this up with help from an AI assistant working from the code. I'm here for the design discussion, not to talk about the coin.

I'm developing V-DAP, an experimental Rust engine that measures cryptographic execution timing. I'm trying to determine whether those measurements provide useful diagnostic information beyond conventional observability tools.

The practical problem I'm investigating is this: when a service experiences latency spikes, can measurements of cryptographic execution help distinguish between possible sources of delay, or do standard metrics, tracing and profiling already provide the same information?

My current experiments are preliminary. In a controlled HTTP pilot, I observed a strong correlation between the measured cryptographic interval and total request latency. In a separate experiment, I introduced a deliberate delay outside that interval and observed the request latency increase. These results demonstrate temporal decomposition in those test conditions, not scheduler causality or a proven diagnostic advantage.

What I want to validate next:

• Can V-DAP help distinguish two known causes of latency?
• Does it improve diagnostic accuracy or time-to-diagnosis compared with conventional tools alone?
• What confounders and measurement overhead should I investigate?
• What experiment would convince you that this has practical engineering value?

Repository and reproducibility details:
https://github.com/jorgecumbe0077/v-dap-engine

I'm looking for critical technical feedback, including reasons this approach may not be useful. I don't claim that V-DAP is production-ready or that it prevents timeouts.

Hey everyone,

ECDSA remains widely implemented across asymmetric cryptosystems, but its existential dependency is an unpredictable, uniform ephemeral scalar: the nonce k must never repeat or exhibit bias under the same private key.

When an implementation relies on a broken pseudo-random number generator (such as flaws in random seed generation or low-entropy PRNGs), two signatures generated with an identical nonce allow algebraic recovery of the signer's private key via basic modular arithmetic.

I developed an open-source research tool called RSZ-Scanner to parse signature tuples (r, s), extract message digests (z), and identify nonce collisions across signature sets. Here is a brief mathematical overview of the recovery pipeline.

**Mathematical Model**

In standard ECDSA over secp256k1, a signature is the pair (r, s):

r = (k \* G)_x mod n
s = k\^(-1) \* (z + r \* d) mod n

Where:
\- G is the generator point of the elliptic curve group.
\- n is the group order.
\- d is the private scalar (secret key).
\- z is the cryptographic message hash truncated to group order length.
\- k is the ephemeral random scalar in \[1, n - 1\].

**Explicit Recovery on Identical Nonces (k1 = k2)**

If a public key signs two distinct message digests z1 and z2 using the exact same nonce k, both signatures share the identical r parameter:

s1 = k\^(-1) \* (z1 + r \* d) mod n
s2 = k\^(-1) \* (z2 + r \* d) mod n

Subtracting the equations eliminates the secret key d:

s1 - s2 = k\^(-1) \* (z1 - z2) mod n

Solving directly for the ephemeral secret k:

k = (z1 - z2) / (s1 - s2) mod n

Once k is known, the private key d is recovered via direct substitution:

d = (s1 \* k - z1) / r mod n

**Implementation Details: RSZ-Scanner**

RSZ-Scanner was written to demonstrate and evaluate this phenomenon against arbitrary signature dumps:

1. Tuple Extraction: Parses signature structures to extract raw (r, s, z) components.
   
2. Collision Detection: Maps and indexes unique r values against corresponding public keys to detect duplicate nonces across large datasets.
   
3. Modular Solver & Verification: Runs the inverse arithmetic above and validates the derived private scalar against the associated EC public point.
   

4. Discrete Log Search: Includes an implementation of the Baby-Step Giant-Step (BSGS) algorithm to handle bounded partial nonce leakage and small nonce offsets.

   **Repository & Discussion**

The implementation is open-source under the MIT license:
https://github.com/harshjamdar/RSZ-Scanner

I would appreciate feedback on:
\- Numerical optimizations for modular inverse computations when processing large batch sizes.
\- Extending BSGS search ranges or evaluating lattice-based attacks (Hidden Number Problem / Bleichenbacher-style lattices) for biased nonces.
\- Verifying edge-case handling around high-s malleable signatures.

Feedback, theoretical critiques, and contributions are welcome!

I have been looking into how high-traffic websites handle crypto deposits. Usually, you have to wait for the network to fully confirm the transaction, which can take a while. But I have noticed that some platforms update your account balance almost immediately after the transaction is broadcasted, like how parimatch seems to credit these instantly. From a technical side, how do they safely do this without risking double-spends? Do they just track the transaction in the mempool and accept the risk internally, or is there a safer way they verify it off-chain?

Hey everyone! I’m building a wallet that lets users delegate actions to an AI agent, and I’m researching wallet infrastructure providers to get started. I’m currently looking at Privy, Turnkey, Dynamic, and Web3Auth.

If you’ve built with any of these, what did you like most, and what limitations did you run into? I really appriciate any suggestions～

I shorted ETH with $100 at 20x leverage on Kraken and paid:

$16 opening fee
$16 closing fee
$5 margin fee

Made $7 gross but lost $30 after fees. A $1482 price drop breaks even but that doesn't even happen in a year...

Ideally, I want to short BTC from $80,144 to $79,673 (red to blue line in screenshot) using $100 at 20x leverage. That’s $11.76 gross profit, but Kraken’s fees wipe it out.

Any platforms that allow shorting with zero or very low fees so I can keep most of the profit?

I’ve been developing V-DAP, an experimental Rust engine that measures cryptographic execution timing. I’m now trying to answer a practical question: can these measurements help diagnose request latency in ways that conventional metrics, logs, and traces do not?

So far, I’ve run controlled experiments that explore the relationship between cryptographic execution time and total request latency. The results are preliminary, and I haven’t established that V-DAP provides better diagnostics in real production systems.

I’ve published the source code, reproduction instructions, experimental reports, and current validation criteria.

Repository: https://github.com/jorge-cumbe0077/v-dap-engine

I’d appreciate technical feedback, especially on:

• Whether the measurement methodology is sound.
• What limitations or confounding factors I may be overlooking.
• How to design a fair comparison against conventional observability tools.
• What evidence would be needed to establish a useful real-world application.

I’m particularly interested in critical feedback that could help validate or invalidate the approach.

Public indexes map hundreds of thousands of addresses to "claimable" balances in dead protocols. Almost none of those numbers are checked against the contract that would pay them, and three failure modes recur.

1. Token counts labelled as ETH. One 2016 index lists 81,295 "ETH" for 4,836 addresses in a DAO wrapper. The wrapper does hold 81,287 ETH, but the top listed holder has 10,200 DAO tokens, not 10,200 ETH, and withdraw() reverts for that address. The file's own header says balance_source: token.

2. A getter that does not answer. One game contract is indexed at 163.42 ETH for its top holder; balanceOf(0x0, holder) returns zero. The pool holds 2,424 ETH, so the money is real and the address mapping is wrong.

3. A payout that is not the getter. Another indexed 141.97 ETH for its top holder, while the contract's own curve function returns 87.83 ETH. A token count was priced as if 1:1.

The method that catches all three, in order:

- Denomination. Only eth-sourced balances count as ETH. Token, weth and vault sources need a per-pool rate and must never be summed into an ETH total.

- Selector provenance. Pull PUSH4 constants out of the deployed runtime bytecode and match them to signatures. Do not trust an ABI, and do not trust an index's stated claim path.

- Getter read. Ask the contract what it owes a specific address.

- Claim simulation. eth_call the actual withdrawal from the holder's address. A revert means there is nothing collectable there, whatever the index says.

- Executor. Decide whether the claim is owner-only (pays msg.sender) or third-party (anyone can trigger payout to the registered recipient, as with merkle airdrops and bridge finalisations). This single axis decides whether a public-good claimer is even possible.

Run against a 2020-era exchange contract, this verified a pool holding 15,673 ETH across 119,430 addresses, with a 946 ETH top holder whose withdrawal simulates cleanly at 42,077 gas, using a different claim selector than the better-known EtherDelta-style contract it resembles.

The uncomfortable part is economics, not cryptography. Where the claim pays msg.sender, no relayer or incentive contract can collect for someone else. Of the 400 largest holders, 97% signed a transaction historically but only 4.5% have signed one in the last year. Chain state cannot distinguish a lost key from indifference, and a lost key makes the balance permanently unrecoverable.

I have a read-only checker that runs the whole read in one call and prints the exact transaction per claim. Not linking it here given the self-promotion rules - comment or message me and I will send it with the raw JSON-RPC body so you can replay it against your own node.

URGENT: President Trump is now aware of the Samourai Wallet developers and has stated he will be looking into a pardon. This is a rare opportunity to change the course of history, but we must keep the pressure on to ensure this gets across the finish line. More than ever, we need you to sign the petition and get your friends and family to do the same. Let's make sure they can't ignore us! See President Trump's comment here.

The problem isn't necessarily whether a quantum computer capable of breaking today's cryptography exists today.

It's whether we can afford to wait until it does.

Cryptographic migrations take time. Wallets need updates. Protocols need new standards. Exchanges, institutions, infrastructure and users all need to migrate.

And once the threat becomes obvious, everyone will be trying to do the same thing at once.

So I'm curious where people here stand:

1. Quantum attacks are still too far away to worry about.
2. We should start preparing now, even if the threat is decades away.
3. Bitcoin and other networks will adapt naturally when the time comes.
4. The quantum threat is being seriously underestimated.

What do you think?