← back

The stuff you haven't firmed up Miner incentive is already handled, but it's thin at low volume. Miners earn standard tx fees on every VEIL transaction (lock, claim, refund, change outputs). A single swap generates 2-3 Blocknet transactions. That's 2-3x the fees of a regular payment. But at low volume, that's a rounding error on a miner's revenue. The honest framing is: miners don't need a special incentive because they don't do anything special. VEIL is gravy on top of block rewards, not a reason to mine. That's fine — you don't need miners to want VEIL activity, you just need them to not refuse it, and they can't refuse it because they can't see it. The real incentive question is about market makers, not miners. Miners are covered. The open problem is: who sits on both sides of BNT trading pairs with enough size to fill orders? Market makers profit from the bid-ask spread — they buy at one price and sell at a slightly higher price. On VEIL, their only cost is transaction fees on both chains. No exchange listing fee, no API costs, no regulatory overhead. The margin is small but so are the costs. The question is whether enough market makers show up to provide liquidity across enough pairs. This is a business development problem, not a protocol problem, but it determines whether VEIL is usable in practice. You might want to think about whether market makers get any protocol-level advantage. Not a fee, but something like priority matching, or a signal that an order has been live for a long time (indicating a committed market maker vs. a one-off trader). Nothing that breaks privacy — just quality-of-life for the people providing liquidity. This doesn't require consensus changes, it's just p2p layer logic. Things you might not be considering The always-online requirement is a UX wall. Both parties need to be online for the entire swap duration — from negotiation through lock confirmations through claim. Depending on block times, that could be 30-60 minutes of both nodes running. If either side's machine sleeps, loses internet, or crashes mid-swap, the trade stalls and both sides wait for the refund timeout. For technical users running a server, this is fine. For a normal person on a laptop, this is a problem. Think about whether there's a way to delegate the "watch and claim" step to a persistent process — something that runs even if the wallet UI is closed. Confirmation times make this slow compared to everything else. A centralized exchange settles in milliseconds. A DEX settles in one block (~12 seconds on Ethereum). A VEIL swap needs confirmations on two chains. If one of them is Bitcoin (6 confirmations, ~60 minutes for high-value trades), that's a long wait. For small trades you can accept fewer confirmations and move faster, but you're trading security for speed. This is fine for the target audience (people who value privacy and self-custody over speed), but it's worth being explicit about it. VEIL is not competing with Binance on speed. It's competing on "your money doesn't get stolen." The two-hop swap needs TWO counterparties simultaneously. A BTC→ETH swap through BNT requires someone selling BNT for BTC AND someone selling ETH for BNT, at compatible prices, at the same time, both online. At low liquidity, finding both matches is hard. The wallet could handle this by splitting it into two independent swaps (user manually holds BNT between legs), but the smooth "swap BTC for ETH" UX requires both legs to be matchable. This gets easier as liquidity grows but could be painful early on. Price discovery is weird without persistent history. The order book is ephemeral. Orders disappear when nodes go offline. There's no trade history, no charts, no volume data. A new user opening VEIL has no idea what the "right" price is for BNT/BTC. They see whatever orders happen to be live at that moment. You might want to think about whether nodes can optionally publish anonymized price data (last trade price, 24h volume) as p2p gossip — not linked to any identity or trade, just aggregate market data. This doesn't require consensus and doesn't compromise privacy, but it helps users make informed decisions. Chain monitoring is resource-intensive. To complete a swap, the user's node needs to watch the counterparty chain for the maker's claim (to extract the adaptor secret). That means the node needs some kind of connection to the counterparty chain — either a full node, a light client, or an RPC connection to a trusted server. Running full nodes for every chain you want to trade with is impractical. Light clients or SPV verification for counterparty chains is the realistic path, but each one is a dependency to build and maintain. Without a consensus fork, verify that timelocks already work. The refund mechanism relies on pre-signed transactions with a locktime — the miner won't include them until a certain block height. Does Blocknet already have nLockTime or equivalent transaction-level timelocking? If yes, no problem. If not, that's the one thing that might force a minimal consensus change, because without timelocks, the entire safety model (worst case is a refund) breaks down. Failed negotiations leak information. When Alice and Bob negotiate and it falls through, Bob now knows Alice's exact terms — what she's selling, how much, at what price. A malicious actor could open hundreds of negotiations with no intention of trading, just to map out market activity. Rate limiting per ephemeral identity helps, but ephemeral identities are cheap to generate. You might want a small proof-of-work cost on the negotiation handshake — enough to make mass probing expensive, not enough to annoy real users. Partial fills would dramatically improve usability but are deferred in the spec. If Alice wants to sell 1000 BNT and Bob only wants to buy 200, the current spec says they can't match. Alice has to find someone who wants exactly 1000, or she posts a 200 BNT order separately. Real markets need partial fills. This is a v2 problem but worth keeping in mind — the state machine and order format should be designed so partial fills can be added later without breaking changes. What happens when Blocknet block rewards decline? If VEIL is meant to be Blocknet's long-term purpose, eventually the transaction fees from VEIL activity need to be sufficient to secure the chain on their own (or alongside reduced block rewards). This is the same sustainability question Bitcoin faces, but with a concrete answer: VEIL gives BNT a reason to generate ongoing transaction volume. The more chains supported, the more trading pairs, the more transactions per swap, the more fees. This is the long game argument for BNT holders — VEIL isn't just a feature, it's the fee revenue model. The one thing I'd firm up first The timelock question. Everything else is design decisions you can iterate on. But if Blocknet doesn't already support transaction-level timelocks, the refund mechanism doesn't work, and that's the entire safety net. Confirm that exists before anything else.