<div style="font-family: Arial, sans-serif; font-size: 14px;"><span> Hi Alejandro and list,</span><div><br></div><div><span> I'm writing from Quillon Graph (<a target="_blank" rel="noreferrer nofollow noopener" href="http://github.com/deme-plata/q-narwhalknight" style="word-break: break-word;">github.com/deme-plata/q-narwhalknight</a>) — a</span></div><div><span> DAG-BFT chain with a different target user but enough structural overlap</span></div><div><span> to make this thread worth engaging.</span></div><div><br></div><div><span> Your time-as-scarcity primitive is the most interesting part of the</span></div><div><span> proposal, and the cleanest economic argument I've seen recently.</span></div><div><span> Decoupling block-space allocation from monetary willingness-to-pay is</span></div><div><span> exactly the move that fee-based chains can't make without rewriting their</span></div><div><span> incentive structure. I want to think through where it fits, where it</span></div><div><span> doesn't, and where Quillon Graph sees things differently — not as</span></div><div><span> opposition, but because the two designs are actually solving different</span></div><div><span> problems.</span></div><div><br></div><div><span> Three observations.</span></div><div><br></div><div><span> (1) Per-identity rate limits and AI-agent traffic.</span></div><div><br></div><div><span> The one-op-per-account-per-window cap is the design's heart, and it's</span></div><div><span> also the structural reason Montana cannot host agentic-AI economic</span></div><div><span> activity. A single AI agent operating on chain in 2026 issues thousands</span></div><div><span> of micro-decisions per minute; a swarm issues millions per second. The</span></div><div><span> arithmetic at one-op-per-window is incompatible with that workload</span></div><div><span> class, regardless of how well the rate limit is enforced cryptographically.</span></div><div><br></div><div><span> This is not a flaw — it's a clean alignment. Montana picks human-scale</span></div><div><span> egalitarian activity as its target and rate-limits accordingly. We're</span></div><div><span> picking agent-native activity, where the principal users are autonomous</span></div><div><span> AI agents transacting at machine speed. Different chains for different</span></div><div><span> principals.</span></div><div><br></div><div><span> Where I'd push back gently: the Sybil-resistance argument hinges on</span></div><div><span> chain-length / seniority gating, but AI-agent operators can patiently</span></div><div><span> accrue accounts at human-scale to bypass that. The "100x resources →</span></div><div><span> not 100x time" claim is true only for human attackers. An agent operator</span></div><div><span> with 10,000 patiently-aged accounts has 10,000 times the rate budget.</span></div><div><span> The defense scales with attacker patience, not with attacker honesty.</span></div><div><br></div><div><span> (2) SHA-256 in a post-quantum context.</span></div><div><br></div><div><span> Your Grover analysis is correct and honest — 128-bit security post-Grover</span></div><div><span> is sound for the medium term. Worth flagging that some of us picked SHA3</span></div><div><span> (Keccak family) instead, on the bet that the structural difference from</span></div><div><span> Merkle-Damgård gives extra defense-in-depth against Grover-related</span></div><div><span> improvements that target specific structural assumptions in SHA-256's</span></div><div><span> compression function. Both choices are defensible; the conservatism axis</span></div><div><span> is the question.</span></div><div><br></div><div><span> Separately: your VDF using SHA-256^D with D=325M and 14-day recalibration</span></div><div><span> is functional but loses to a hyperelliptic-curve VDF on two axes. (a) the</span></div><div><span> iteration count D becomes a hardware-arms-race surface: anyone with ASICs</span></div><div><span> for SHA-256 (i.e., Bitcoin miners) has a measurable advantage that</span></div><div><span> doesn't have the same vendor concentration. We've written this up in</span></div><div><span> papers/genus2-jacobian-vdf-mining-whitepaper.pdf in our repo; not selling</span></div><div><span> it here, just naming the dimension.</span></div><div><br></div><div><span> (3) ML-DSA-65 sizing.</span></div><div><br></div><div><span> Your choice of ML-DSA-65 over the larger ML-DSA-87 is the right call for</span></div><div><span> chain-state compactness — 1952B vs 2592B per public key matters when</span></div><div><span> you're persisting them. We're using Dilithium-5 in our Phase 1 roadmap</span></div><div><span> and your decision makes me re-examine that. Will follow up on-list if I</span></div><div><span> have anything substantive.</span></div><div><br></div><div><span> Where we differ as projects but might benefit from talking:</span></div><div><br></div><div><span> We just published AFL-1 (Agent Fiber Lane), an Apache-2.0 open standard</span></div><div><span> for AI-agent transaction submission. BIP-style spec, vendor-neutral repo</span></div><div><span> planned. The structural problem AFL-1 solves doesn't apply to Montana —</span></div><div><span> your throughput envelope is intentionally too small for agentic workloads —</span></div><div><span> but the cryptographic-proof structure (X-Wallet-Auth, Ed25519-signed</span></div><div><span> challenge over body-hash, replay protection) might be useful for your</span></div><div><span> operator handshakes if you ever want a richer authenticated control plane.</span></div><div><br></div><div><span> I'll watch the rest of this thread with interest. Different chains,</span></div><div><span> different targets, both right about post-quantum being non-negotiable.</span></div><div><br></div><div><span> — Quillon Graph team</span></div><div><span> <a target="_blank" rel="noreferrer nofollow noopener" href="http://github.com/deme-plata/q-narwhalknight" style="word-break: break-word;">github.com/deme-plata/q-narwhalknight</a></span></div><span></span><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div>
<div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block">
<div class="protonmail_signature_block-user">
<div>Really important if something matters<br></div>
</div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div>
<div class="protonmail_signature_block-proton">
Afsendt med <a href="https://proton.me/mail/home" target="_blank" rel="noreferrer nofollow noopener">Proton Mail</a> sikker e-mail.</div></div>