AlizehAli
11.2k Publications
AlizehAli
592 Suivis
24.3K+ Abonnés
8.2K+ J’aime
Publications
Tous
Citations
Direct
PINNED
@Dusk A country's founding constitution exists the moment the country does — nobody votes it into being after the fact, it's simply there at day one, and everything else gets built referencing it.
Dusk's genesis contracts work the same way. Dusk's own architecture materials describe two: the stake contract, tracking which provisioners are staking, recording rewards, and enabling stake, unstake, and reward-withdrawal actions; and the transfer contract, handling both Moonlight (public) and Phoenix (shielded) transfers, paying gas, and acting as the entry point for transaction execution directly on DuskDS.
That foundational role extends further than DuskDS alone, though the exact mechanism differs by layer. DuskEVM, per Dusk's own docs, moves DUSK for gas through its own bridge to Dusk's L1, ultimately settling back to DuskDS — a related but distinct path from the transfer contract's direct role in native DuskDS transactions. Both roads lead back to the same base layer; they aren't identical mechanisms. #dusk
Self-critique: the constitution-analogy has a real limit worth naming. A country's constitution can be formally amended through a defined process. What I haven't found documented is whether Dusk's genesis contracts follow an equivalent, clearly-specified amendment path, or whether "genesis" here functionally means permanent-by-design — a real governance-question given how much of Dusk's expanding multilayer stack now depends on these same two contracts staying correct. $DUSK
DUSK should be evaluated on whether that ambiguity gets clarified before these contracts ever need updating under real pressure, not after.
#dusk $DUSK @Dusk
Dusk's genesis contracts work the same way. Dusk's own architecture materials describe two: the stake contract, tracking which provisioners are staking, recording rewards, and enabling stake, unstake, and reward-withdrawal actions; and the transfer contract, handling both Moonlight (public) and Phoenix (shielded) transfers, paying gas, and acting as the entry point for transaction execution directly on DuskDS.
That foundational role extends further than DuskDS alone, though the exact mechanism differs by layer. DuskEVM, per Dusk's own docs, moves DUSK for gas through its own bridge to Dusk's L1, ultimately settling back to DuskDS — a related but distinct path from the transfer contract's direct role in native DuskDS transactions. Both roads lead back to the same base layer; they aren't identical mechanisms. #dusk
Self-critique: the constitution-analogy has a real limit worth naming. A country's constitution can be formally amended through a defined process. What I haven't found documented is whether Dusk's genesis contracts follow an equivalent, clearly-specified amendment path, or whether "genesis" here functionally means permanent-by-design — a real governance-question given how much of Dusk's expanding multilayer stack now depends on these same two contracts staying correct. $DUSK
DUSK should be evaluated on whether that ambiguity gets clarified before these contracts ever need updating under real pressure, not after.
#dusk $DUSK @Dusk
Permanent by design
Should have amendment path
14 heure(s) restante(s)
PINNED
@TermMax I assumed exercising a profitable option on TermMax Alpha would work one fixed way — payout hits your wallet, done, same as any options platform I'd used before. $BEAT
That assumption fell apart once I read that TermMax actually gives two distinct exercise paths. Exercise-Net-Settle closes the position and pays out the net profit directly. Exercise-Delivery instead settles by transferring the underlying asset itself, not cash — you end up actually holding the token your Long or Short position was based on. #TermMax
This reframes what "winning" an options trade means here. On most platforms, exercising just means realizing a number. On TermMax, exercising can mean walking away with the actual asset, which matters specifically for early Binance Alpha listings where getting real exposure to the token — not just its price movement — might be the whole point of the trade. $TUT
What the docs don't clarify is whether the choice between the two is always available to the trader, or whether it depends on the specific market's configuration at settlement time. $ENA
The real test for TMX is whether traders actually understand this choice exists before they exercise, or default to whichever option the interface shows first.
Has anyone actually used Exercise-Delivery instead of Net-Settle, and why?
#termmax @TermMax
That assumption fell apart once I read that TermMax actually gives two distinct exercise paths. Exercise-Net-Settle closes the position and pays out the net profit directly. Exercise-Delivery instead settles by transferring the underlying asset itself, not cash — you end up actually holding the token your Long or Short position was based on. #TermMax
This reframes what "winning" an options trade means here. On most platforms, exercising just means realizing a number. On TermMax, exercising can mean walking away with the actual asset, which matters specifically for early Binance Alpha listings where getting real exposure to the token — not just its price movement — might be the whole point of the trade. $TUT
What the docs don't clarify is whether the choice between the two is always available to the trader, or whether it depends on the specific market's configuration at settlement time. $ENA
The real test for TMX is whether traders actually understand this choice exists before they exercise, or default to whichever option the interface shows first.
Has anyone actually used Exercise-Delivery instead of Net-Settle, and why?
#termmax @TermMax
Vérifié
@Dusk Went back through Dusk's own architecture announcement from June 2025, and the framing has shifted since Dusk's earlier positioning.
Three layers, according to Dusk's current documentation: DuskDS at the base, consensus, settlement, data availability, native transaction models. DuskEVM on top, OP Stack-based, full Solidity compatibility. DuskVM alongside it, Rust/WASM contracts running directly on L1 for privacy-native use cases. #dusk
What changed from the original 2025 evolution-announcement to now: DuskVM was described as "forthcoming" at that point. Current docs describe it as live infrastructure, not a roadmap item. Separately, Dusk's own 2026 updates describe NPEX's regulated securities dApp actively rolling out on DuskEVM specifically — I want to be precise that this is described as an ongoing rollout, not something I can confirm as a finished, fully-operational launch yet. $DUSK
One detail ties all three layers together concretely, independent of that rollout's status: a single DUSK token fuels every layer, and a validator-run native bridge moves value between them without wrapped assets or custodians.
That's still an evolving system, not a finished one. DuskEVM's own docs confirm it currently runs sequencer-only, with no public mempool yet — a specific, dated limitation sitting underneath whatever's actively deploying on top of it right now.
If anyone's tracked how NPEX's rollout is actually progressing against this architecture in practice, I'd want to compare notes against what I found here.
#dusk $DUSK @Dusk
Three layers, according to Dusk's current documentation: DuskDS at the base, consensus, settlement, data availability, native transaction models. DuskEVM on top, OP Stack-based, full Solidity compatibility. DuskVM alongside it, Rust/WASM contracts running directly on L1 for privacy-native use cases. #dusk
What changed from the original 2025 evolution-announcement to now: DuskVM was described as "forthcoming" at that point. Current docs describe it as live infrastructure, not a roadmap item. Separately, Dusk's own 2026 updates describe NPEX's regulated securities dApp actively rolling out on DuskEVM specifically — I want to be precise that this is described as an ongoing rollout, not something I can confirm as a finished, fully-operational launch yet. $DUSK
One detail ties all three layers together concretely, independent of that rollout's status: a single DUSK token fuels every layer, and a validator-run native bridge moves value between them without wrapped assets or custodians.
That's still an evolving system, not a finished one. DuskEVM's own docs confirm it currently runs sequencer-only, with no public mempool yet — a specific, dated limitation sitting underneath whatever's actively deploying on top of it right now.
If anyone's tracked how NPEX's rollout is actually progressing against this architecture in practice, I'd want to compare notes against what I found here.
#dusk $DUSK @Dusk
Vérifié
@TermMax Spent some time mapping TermMax Alpha's options mechanics, expecting the usual open-ended options risk profile.
That's not what I found. Going Long means buying a call, Short means buying a put, both against a counterparty the docs call Dual Investment — the option seller. Max Cost is defined precisely as the premium paid, denominated primarily in USDT. Settlement runs through Exercise-Net-Settle or Exercise-Delivery, and either way the maximum possible loss was locked the moment the position opened.
None of those terms looked especially significant on their own. But the launch context made me pause. TermMax Alpha went live on BNB Chain mainnet on November 12, 2025, built by Term Structure Labs, backed by Cumberland DRW — a real institutional trading firm, not just a token-listing gimmick.
That backing matters because of what the product actually solves. When Binance Alpha lists a new token, traders often wait weeks before perpetual contracts appear anywhere. TermMax Alpha exists specifically to fill that gap — leveraged exposure with capped, known cost, available from day one of a listing instead of weeks later. #TermMax
What caught my attention is that this makes TermMax Alpha genuinely time-sensitive infrastructure — its relevance is tied to how fast new Binance Alpha listings keep happening, not a static feature sitting still.
I haven't confirmed how many live Alpha markets are currently active, or how tight spreads run on the newest listings.
Long or Short?
#termmax @TermMax
That's not what I found. Going Long means buying a call, Short means buying a put, both against a counterparty the docs call Dual Investment — the option seller. Max Cost is defined precisely as the premium paid, denominated primarily in USDT. Settlement runs through Exercise-Net-Settle or Exercise-Delivery, and either way the maximum possible loss was locked the moment the position opened.
None of those terms looked especially significant on their own. But the launch context made me pause. TermMax Alpha went live on BNB Chain mainnet on November 12, 2025, built by Term Structure Labs, backed by Cumberland DRW — a real institutional trading firm, not just a token-listing gimmick.
That backing matters because of what the product actually solves. When Binance Alpha lists a new token, traders often wait weeks before perpetual contracts appear anywhere. TermMax Alpha exists specifically to fill that gap — leveraged exposure with capped, known cost, available from day one of a listing instead of weeks later. #TermMax
What caught my attention is that this makes TermMax Alpha genuinely time-sensitive infrastructure — its relevance is tied to how fast new Binance Alpha listings keep happening, not a static feature sitting still.
I haven't confirmed how many live Alpha markets are currently active, or how tight spreads run on the newest listings.
Long or Short?
#termmax @TermMax
Long (call)
75%
Short (put)
0%
Neither, too risky
25%
4 Votes • Vote fermé
·
--
🎙️ Now who is who and what is what. What Binance actually wants 😂😂
Fin
01 h 56 min 10 sec
431
0
SNARK-friendly hash function designed by Dusk's own team specifically for collision-resistant hashing inside zero-knowledge circuits.
Mohsin_Trader_King
·
--
Been sitting with a question Dusk's documentation doesn't directly answer with hard numbers: can two different Phoenix notes ever produce the same nullifier.
What I can confirm precisely: Dusk's own Phoenix repository states the nullifier is computed specifically so an external observer can't link it back to which note it came from. Each note gets hashed into leaves of a Merkle tree of notes, and spending one produces a deterministic nullifier value tied to that specific note's data.
The hashing underneath this — across Dusk's Merkle tree structure and broader cryptographic operations — runs on Poseidon, a SNARK-friendly hash function designed by Dusk's own team specifically for collision-resistant hashing inside zero-knowledge circuits. That's not a generic hash borrowed off the shelf; it's purpose-built for exactly this kind of ZK-native commitment work.
But collision-resistant isn't the same as collision-proof. Any hash function, Poseidon included, carries a theoretical (astronomically small) chance of two different inputs producing the same output — that's the nature of hashing itself, not a Dusk-specific weakness.
What I haven't found in Dusk's own materials is any published collision-probability figure specific to their exact Poseidon parameters, or documentation of dedicated collision-testing beyond the general security properties Poseidon inherits by design.
If anyone's seen an audit report covering this specific property for Dusk's implementation, I'd like to compare it against what's publicly documented.
#dusk $DUSK @Dusk
What I can confirm precisely: Dusk's own Phoenix repository states the nullifier is computed specifically so an external observer can't link it back to which note it came from. Each note gets hashed into leaves of a Merkle tree of notes, and spending one produces a deterministic nullifier value tied to that specific note's data.
The hashing underneath this — across Dusk's Merkle tree structure and broader cryptographic operations — runs on Poseidon, a SNARK-friendly hash function designed by Dusk's own team specifically for collision-resistant hashing inside zero-knowledge circuits. That's not a generic hash borrowed off the shelf; it's purpose-built for exactly this kind of ZK-native commitment work.
But collision-resistant isn't the same as collision-proof. Any hash function, Poseidon included, carries a theoretical (astronomically small) chance of two different inputs producing the same output — that's the nature of hashing itself, not a Dusk-specific weakness.
What I haven't found in Dusk's own materials is any published collision-probability figure specific to their exact Poseidon parameters, or documentation of dedicated collision-testing beyond the general security properties Poseidon inherits by design.
If anyone's seen an audit report covering this specific property for Dusk's implementation, I'd like to compare it against what's publicly documented.
#dusk $DUSK @Dusk
5% goes to the liquidator as their reward for executing the liquidation
Mohsin_Trader_King
·
--
Went back through TermMax's liquidation docs specifically to trace where the penalty money actually ends up.
The number is simple: 10% of the liquidated debt value, pulled from the borrower's own collateral whenever liquidation fires. What's less obvious is the split — not one lump sum to one party. 5% goes to the liquidator as their reward for executing the liquidation. The other 5% routes directly to the protocol's own reserve.
What changed for me was realizing this isn't just a punishment fee, it's a two-part incentive structure the docs frame explicitly around protocol stability — designed to maintain the required LTV on loans while giving liquidators a real reason to act fast. The formula confirms the priority order too: liquidated collateral first covers the liquidator reward, then the remainder applies to the protocol penalty, all explicitly capped to the borrower's actual position — meaning the penalty mathematically can't exceed what that borrower's own collateral can cover, no matter how the formula runs.
Worth flagging: the docs specify the split and the cap clearly, but don't state what the reserve is spent on once it accumulates, or under what conditions it gets drawn down.
Next thing I'd check: how large that reserve has actually grown relative to total liquidation volume so far.
#termmax @TermMax $BTW
$RICE
$GPS
The number is simple: 10% of the liquidated debt value, pulled from the borrower's own collateral whenever liquidation fires. What's less obvious is the split — not one lump sum to one party. 5% goes to the liquidator as their reward for executing the liquidation. The other 5% routes directly to the protocol's own reserve.
What changed for me was realizing this isn't just a punishment fee, it's a two-part incentive structure the docs frame explicitly around protocol stability — designed to maintain the required LTV on loans while giving liquidators a real reason to act fast. The formula confirms the priority order too: liquidated collateral first covers the liquidator reward, then the remainder applies to the protocol penalty, all explicitly capped to the borrower's actual position — meaning the penalty mathematically can't exceed what that borrower's own collateral can cover, no matter how the formula runs.
Worth flagging: the docs specify the split and the cap clearly, but don't state what the reserve is spent on once it accumulates, or under what conditions it gets drawn down.
Next thing I'd check: how large that reserve has actually grown relative to total liquidation volume so far.
#termmax @TermMax $BTW
$RICE
$GPS
Vérifié
@Dusk Went looking for what actually happens when a Phoenix zero-knowledge proof fails verification, since most explanations stop at "the proof gets checked."
Dusk's architecture confirms the proof has to demonstrate specific properties together — ownership of the note being spent, balance integrity across inputs and outputs, and no double-spend — all encoded inside the same proof, not verified through separate side-checks. $DUSK
That's the part worth sitting with. If any single one of those properties doesn't hold, the entire proof fails as one unit. There's no partial-credit path where balance checks pass but ownership fails silently.
I traced what that means practically: a rejected proof means the transaction never gets included at all. The runtime doesn't attempt to salvage or partially process it. The transaction simply doesn't happen, and nothing about the failed attempt gets recorded as a state change. #dusk
What I haven't confirmed from Dusk's own materials is whether a failed proof leaves any trace in mempool logs that a node operator could inspect after the fact, or whether it's discarded without any diagnostic record at all.
Next thing I'd check: whether Dusk's current wallet tooling surfaces a specific reason for a failed proof, or just a generic rejection, since that distinction matters a lot for anyone actually debugging a transaction that didn't go through.
#dusk $DUSK @Dusk
Dusk's architecture confirms the proof has to demonstrate specific properties together — ownership of the note being spent, balance integrity across inputs and outputs, and no double-spend — all encoded inside the same proof, not verified through separate side-checks. $DUSK
That's the part worth sitting with. If any single one of those properties doesn't hold, the entire proof fails as one unit. There's no partial-credit path where balance checks pass but ownership fails silently.
I traced what that means practically: a rejected proof means the transaction never gets included at all. The runtime doesn't attempt to salvage or partially process it. The transaction simply doesn't happen, and nothing about the failed attempt gets recorded as a state change. #dusk
What I haven't confirmed from Dusk's own materials is whether a failed proof leaves any trace in mempool logs that a node operator could inspect after the fact, or whether it's discarded without any diagnostic record at all.
Next thing I'd check: whether Dusk's current wallet tooling surfaces a specific reason for a failed proof, or just a generic rejection, since that distinction matters a lot for anyone actually debugging a transaction that didn't go through.
#dusk $DUSK @Dusk
@TermMax Spent some time mapping TermMax's three-token system, and one line in the docs reframed the whole thing for me: Collateral Value equals GT Value plus the Value of the Loan itself, where GT Value is defined as Collateral minus the Value of Debt. The tokens aren't just three separate objects, they're pieces of one equation that has to balance.
FT is an ERC-20, functioning as a zero-coupon bond — 110 FT-USDC redeems for 110 USDC at maturity, so buying it for 100 USDC locks a 10% return over a one-year term. But the docs specify that number scales with maturity, not just holds constant — a 180-day FT at the same discount annualizes to roughly 20%, not 10%. XT is defined more precisely than I expected too: it's not just "the other half," it's specifically the present value of the interest the borrower owes, separated out from the principal. GT is the position wrapper — ERC-721, tracking collateral and debt as one unit, capped by MLTV.
What caught my attention is that XT isn't filler, it's a distinct financial instrument representing interest risk on its own, priced separately from FT's principal risk. Splitting principal from interest at the token level is what makes the whole system's zero-sum equation hold — no value appears or vanishes anywhere in the chain. #TermMax
The missing piece for me is real secondary-market depth for XT specifically, since it's pricing something as narrow as short-term interest risk alone.
"Which token matters most to you?"
#termmax
@TermMax
FT is an ERC-20, functioning as a zero-coupon bond — 110 FT-USDC redeems for 110 USDC at maturity, so buying it for 100 USDC locks a 10% return over a one-year term. But the docs specify that number scales with maturity, not just holds constant — a 180-day FT at the same discount annualizes to roughly 20%, not 10%. XT is defined more precisely than I expected too: it's not just "the other half," it's specifically the present value of the interest the borrower owes, separated out from the principal. GT is the position wrapper — ERC-721, tracking collateral and debt as one unit, capped by MLTV.
What caught my attention is that XT isn't filler, it's a distinct financial instrument representing interest risk on its own, priced separately from FT's principal risk. Splitting principal from interest at the token level is what makes the whole system's zero-sum equation hold — no value appears or vanishes anywhere in the chain. #TermMax
The missing piece for me is real secondary-market depth for XT specifically, since it's pricing something as narrow as short-term interest risk alone.
"Which token matters most to you?"
#termmax
@TermMax
FT (fixed yield)
67%
XT (interest pricing)
33%
GT (leverage wrapper)
0%
All three together
0%
6 Votes • Vote fermé
@TermMax I assumed liquidation on TermMax meant the same thing it means everywhere else I've used — cross the danger line, lose the whole position in one shot, no in-between.
That assumption fell apart once I read the actual formula. Liquidation triggers one of two ways: LTV meets or exceeds the market's LLTV threshold, or the borrower misses the fixed maturity repayment, which opens a two-hour liquidation window regardless of price. $ACE
Here's the number that reframed things. If outstanding debt exceeds $10,000, liquidators are capped at 50% of total debt value per event. The maximum liquidatable collateral is calculated as total collateral times liquidated debt, divided by total debt — a ratio built so LTV improves after every liquidation instead of collapsing to zero. Full liquidation only happens if debt drops to exactly zero, at which point remaining collateral auto-returns to the borrower.
The penalty is 10% of liquidated debt value, split exactly in half — 5% to the liquidator as reward, 5% to the protocol's reserve vault.
What the docs don't say is what share of real positions actually cross $10,000 in debt versus staying under that line, where the cap wouldn't even apply. $CLO
The real test for TMX is whether that 50% cap protects large borrowers meaningfully, or just turns one liquidation into two smaller ones back to back. $CYS
Anyone tracked partial-versus-full liquidation counts on TermMax so far?
#termmax @TermMax
That assumption fell apart once I read the actual formula. Liquidation triggers one of two ways: LTV meets or exceeds the market's LLTV threshold, or the borrower misses the fixed maturity repayment, which opens a two-hour liquidation window regardless of price. $ACE
Here's the number that reframed things. If outstanding debt exceeds $10,000, liquidators are capped at 50% of total debt value per event. The maximum liquidatable collateral is calculated as total collateral times liquidated debt, divided by total debt — a ratio built so LTV improves after every liquidation instead of collapsing to zero. Full liquidation only happens if debt drops to exactly zero, at which point remaining collateral auto-returns to the borrower.
The penalty is 10% of liquidated debt value, split exactly in half — 5% to the liquidator as reward, 5% to the protocol's reserve vault.
What the docs don't say is what share of real positions actually cross $10,000 in debt versus staying under that line, where the cap wouldn't even apply. $CLO
The real test for TMX is whether that 50% cap protects large borrowers meaningfully, or just turns one liquidation into two smaller ones back to back. $CYS
Anyone tracked partial-versus-full liquidation counts on TermMax so far?
#termmax @TermMax
Vérifié
@Dusk Checked how Dusk frames itself against Ethereum specifically, since most privacy-chain comparisons default to Zcash or Monero instead.
Dusk's current homepage states the target plainly: infrastructure for regulated digital assets, confidential by default, with zero-knowledge proofs and controlled visibility for audit and regulated disclosure. That's a notably sharper framing than Dusk's earlier public positioning, which centered more on combining Moonlight's public transactions with Phoenix's privacy-preserving model for regulated finance broadly, without leaning as hard on a direct Ethereum-transparency contrast.
What changed between those framings is worth sitting with. Ethereum's default — every balance, every call, visible to anyone — works fine for public coordination. Dusk's DuskEVM runs full EVM equivalence using the same tooling Ethereum developers already know, while keeping Dusk's shielded-by-default posture underneath. The execution model isn't being rejected. The visibility default is. $DUSK
Dusk's own site lists specific EU-regulated partners now actively building on this positioning — a licensed market infrastructure provider under the DLT Pilot Regime, plus a European regulated venue exploring on-chain issuance directly through this framing.
That's real institutional movement, not just messaging — but whether it adds up to meaningful developer migration away from Ethereum-first stacks specifically because of the transparency issue is something I haven't found adoption numbers to confirm either way. #dusk
If anyone's tracked actual migration data tied specifically to the transparency argument, rather than to Dusk's broader compliance pitch, I'd want to compare that against what's publicly named on Dusk's own partner list.
#dusk $DUSK @Dusk
Dusk's current homepage states the target plainly: infrastructure for regulated digital assets, confidential by default, with zero-knowledge proofs and controlled visibility for audit and regulated disclosure. That's a notably sharper framing than Dusk's earlier public positioning, which centered more on combining Moonlight's public transactions with Phoenix's privacy-preserving model for regulated finance broadly, without leaning as hard on a direct Ethereum-transparency contrast.
What changed between those framings is worth sitting with. Ethereum's default — every balance, every call, visible to anyone — works fine for public coordination. Dusk's DuskEVM runs full EVM equivalence using the same tooling Ethereum developers already know, while keeping Dusk's shielded-by-default posture underneath. The execution model isn't being rejected. The visibility default is. $DUSK
Dusk's own site lists specific EU-regulated partners now actively building on this positioning — a licensed market infrastructure provider under the DLT Pilot Regime, plus a European regulated venue exploring on-chain issuance directly through this framing.
That's real institutional movement, not just messaging — but whether it adds up to meaningful developer migration away from Ethereum-first stacks specifically because of the transparency issue is something I haven't found adoption numbers to confirm either way. #dusk
If anyone's tracked actual migration data tied specifically to the transparency argument, rather than to Dusk's broader compliance pitch, I'd want to compare that against what's publicly named on Dusk's own partner list.
#dusk $DUSK @Dusk
@Dusk used to assume a verifier on Dusk needed to see a transaction's details to confirm it was legitimate.
That's not what happens with Phoenix.
I traced what the verifier actually receives instead of the raw data. Dusk's own architecture materials confirm Phoenix uses zero-knowledge proofs specifically to prove ownership of unspent outputs and prevent double-spending — the verifier checks the proof, not the transaction itself.
Hmm.
so what's actually inside that proof, mechanically?
Sat with this for a while. A spender proves knowledge of the path to the Merkle tree's root, and knowledge of the commitment's opening — meaning the proof mathematically demonstrates the note exists in the tree and the spender genuinely knows what's inside it, without exposing either the note's contents or its location to anyone watching.
Spending itself requires a Secret Key known exclusively to the note's owner — so even the proof-generation step can't happen without the one piece of information nobody else has.
That's a stranger guarantee than it first sounds. The verifier isn't trusting the sender's word. It isn't trusting a third party either. It's confirming a mathematical statement — tree-membership plus commitment-knowledge — holds true, without ever reconstructing what made it true.
Not saying that's a weaker check. If anything, refusing to look might be the whole point — the verifier can't be tricked by data it never receives in the first place.
Does a system built to verify tree-membership and secret-key-knowledge, without ever seeing amounts, earn more trust than one that verifies by looking directly at the data?
@Dusk #dusk $DUSK
That's not what happens with Phoenix.
I traced what the verifier actually receives instead of the raw data. Dusk's own architecture materials confirm Phoenix uses zero-knowledge proofs specifically to prove ownership of unspent outputs and prevent double-spending — the verifier checks the proof, not the transaction itself.
Hmm.
so what's actually inside that proof, mechanically?
Sat with this for a while. A spender proves knowledge of the path to the Merkle tree's root, and knowledge of the commitment's opening — meaning the proof mathematically demonstrates the note exists in the tree and the spender genuinely knows what's inside it, without exposing either the note's contents or its location to anyone watching.
Spending itself requires a Secret Key known exclusively to the note's owner — so even the proof-generation step can't happen without the one piece of information nobody else has.
That's a stranger guarantee than it first sounds. The verifier isn't trusting the sender's word. It isn't trusting a third party either. It's confirming a mathematical statement — tree-membership plus commitment-knowledge — holds true, without ever reconstructing what made it true.
Not saying that's a weaker check. If anything, refusing to look might be the whole point — the verifier can't be tricked by data it never receives in the first place.
Does a system built to verify tree-membership and secret-key-knowledge, without ever seeing amounts, earn more trust than one that verifies by looking directly at the data?
@Dusk #dusk $DUSK
@TermMax used to think a loan just showed up as a number sitting in some account balance.
the more i looked at how TermMax actually structures a position, the less that held up.
a borrower locks collateral. TermMax mints a Gearing Token against it, an ERC-721, not a ledger entry. the debt token, the collateral token, and the maturity date are all fixed at the market level before that GT even exists.
the GT itself records exactly two things. how much collateral sits inside it. how many Fixed-Rate Tokens have been minted against that collateral, capped by the market's max loan-to-value. an MLTV of 0.8, for example, turns 1 ETH into up to 800 $USDC of mintable debt. #TermMax
no shared pool, no netting, no blended number anywhere in the design.
reread that isolation part twice. TermMax runs 100+ markets as of its March 2026 update, each one sealed off from the others, so one bad collateral price in one market never touches the GTs sitting in any other. not bookkeeping. a boundary.
repay with debt tokens directly, or buy back the FTs on the open market and hand those back instead. either way the GT closes and collateral releases, but it never merged with anyone else's numbers to begin with.
so borrowing on TermMax isn't one number that grows or shrinks. it's as many GTs as you've opened, each carrying its own collateral, its own debt, its own maturity, on its own.
does per-loan tracking make risk clearer, or just harder to manage at scale?
@TermMax #termmax
the more i looked at how TermMax actually structures a position, the less that held up.
a borrower locks collateral. TermMax mints a Gearing Token against it, an ERC-721, not a ledger entry. the debt token, the collateral token, and the maturity date are all fixed at the market level before that GT even exists.
the GT itself records exactly two things. how much collateral sits inside it. how many Fixed-Rate Tokens have been minted against that collateral, capped by the market's max loan-to-value. an MLTV of 0.8, for example, turns 1 ETH into up to 800 $USDC of mintable debt. #TermMax
no shared pool, no netting, no blended number anywhere in the design.
reread that isolation part twice. TermMax runs 100+ markets as of its March 2026 update, each one sealed off from the others, so one bad collateral price in one market never touches the GTs sitting in any other. not bookkeeping. a boundary.
repay with debt tokens directly, or buy back the FTs on the open market and hand those back instead. either way the GT closes and collateral releases, but it never merged with anyone else's numbers to begin with.
so borrowing on TermMax isn't one number that grows or shrinks. it's as many GTs as you've opened, each carrying its own collateral, its own debt, its own maturity, on its own.
does per-loan tracking make risk clearer, or just harder to manage at scale?
@TermMax #termmax
Vérifié
@Dusk used to think "selective disclosure" was just a softer word for transparency.
Sat with Citadel's actual design for a while, and it isn't.
Full transparency, the kind Dusk explicitly builds against, means every observer sees every attribute tied to a transaction or identity, whether they need it or not. Citadel does something narrower, and I traced the actual mechanics: three distinct parties, not two. A User requests a license on-chain from a License Provider. Once issued, that license lets the User establish a private, off-chain connection with a Service Provider — who verifies the claim using only what's stored on-chain, never learning the User's underlying identity.
Hmm.
so what does the Service Provider actually learn when a check passes?
Just that one claim is true — residency, age bracket, accreditation, whatever the license covers. Not the underlying data behind it, not any other attribute the User holds, not a persistent identifier linking this check to a future one.
That's a much narrower promise than transparency makes. A fully transparent system tells everyone everything, permanently, whether it's relevant or not. Citadel's three-party structure tells one Service Provider one true thing, verified against an on-chain record, without that Service Provider ever touching the User's full profile.
Not saying transparency is wrong everywhere. Public coordination genuinely benefits from everyone seeing the same ledger. But identity-gated actions — proving eligibility without volunteering a full profile — needed a protocol with three separate roles, not two, to actually work.
Is proving one true thing through three separated roles a stronger privacy guarantee than transparency's "everyone sees everything, so no one's hiding anything"?
@Dusk #dusk $DUSK
Sat with Citadel's actual design for a while, and it isn't.
Full transparency, the kind Dusk explicitly builds against, means every observer sees every attribute tied to a transaction or identity, whether they need it or not. Citadel does something narrower, and I traced the actual mechanics: three distinct parties, not two. A User requests a license on-chain from a License Provider. Once issued, that license lets the User establish a private, off-chain connection with a Service Provider — who verifies the claim using only what's stored on-chain, never learning the User's underlying identity.
Hmm.
so what does the Service Provider actually learn when a check passes?
Just that one claim is true — residency, age bracket, accreditation, whatever the license covers. Not the underlying data behind it, not any other attribute the User holds, not a persistent identifier linking this check to a future one.
That's a much narrower promise than transparency makes. A fully transparent system tells everyone everything, permanently, whether it's relevant or not. Citadel's three-party structure tells one Service Provider one true thing, verified against an on-chain record, without that Service Provider ever touching the User's full profile.
Not saying transparency is wrong everywhere. Public coordination genuinely benefits from everyone seeing the same ledger. But identity-gated actions — proving eligibility without volunteering a full profile — needed a protocol with three separate roles, not two, to actually work.
Is proving one true thing through three separated roles a stronger privacy guarantee than transparency's "everyone sees everything, so no one's hiding anything"?
@Dusk #dusk $DUSK
Stronger guarantee
100%
Transparency is simpler
0%
4 Votes • Vote fermé
Dusk's own repository states the nullifier is computed specifically so an external observer cannot link it to any particular note.
precious Zarmalaa
·
--
What a Nullifier Actually Stops From Happening Twice
I checked what specifically a nullifier prevents on Dusk, since "prevents double-spending" gets said without much precision.
It stops the same shielded note from being spent more than once — nothing broader than that.
I traced how Dusk does this without revealing which note was spent. Dusk's own repository states the nullifier is computed specifically so an external observer cannot link it to any particular note. The network doesn't check the note itself against a list; it checks whether this exact nullifier has already appeared.
I confirmed the note doesn't get removed from anywhere once spent. It stays recorded in Dusk's Merkle tree of notes. Only the nullifier gets added to a separate, growing record.
That distinction matters. If notes were deleted on spend, I'd expect that to leak timing information just from watching the structure shrink. Keeping every note in place, spent or not, removes that particular signal.
I looked for whether this creates any collision risk — two different notes accidentally producing the same nullifier. I found no documented case of that in Dusk's own materials, though the guarantee rests on the same underlying cryptographic assumptions the rest of the system depends on.
So a nullifier on Dusk isn't really "marking" a note as spent in any visible sense. It's proving a spend happened, without identifying what was spent.
Does preventing double-spends this way protect more privacy than it's worth in permanent, ever-growing storage?
@Dusk #dusk $DUSK #dusk
I checked what specifically a nullifier prevents on Dusk, since "prevents double-spending" gets said without much precision.
It stops the same shielded note from being spent more than once — nothing broader than that.
I traced how Dusk does this without revealing which note was spent. Dusk's own repository states the nullifier is computed specifically so an external observer cannot link it to any particular note. The network doesn't check the note itself against a list; it checks whether this exact nullifier has already appeared.
I confirmed the note doesn't get removed from anywhere once spent. It stays recorded in Dusk's Merkle tree of notes. Only the nullifier gets added to a separate, growing record.
That distinction matters. If notes were deleted on spend, I'd expect that to leak timing information just from watching the structure shrink. Keeping every note in place, spent or not, removes that particular signal.
I looked for whether this creates any collision risk — two different notes accidentally producing the same nullifier. I found no documented case of that in Dusk's own materials, though the guarantee rests on the same underlying cryptographic assumptions the rest of the system depends on.
So a nullifier on Dusk isn't really "marking" a note as spent in any visible sense. It's proving a spend happened, without identifying what was spent.
Does preventing double-spends this way protect more privacy than it's worth in permanent, ever-growing storage?
@Dusk #dusk $DUSK #dusk
Vérifié
@Dusk kept assuming eligibility on Dusk was something you earned once and kept, like a badge that stayed pinned.
it's actually three separate mechanisms working together, and any one of them can take it away.
first: the minimum stake. i confirmed a Dusk provisioner needs 1000 DUSK locked, and below that threshold, nothing else about the stake matters.
second: maturity. even a stake above the minimum has to sit through a fixed number of epochs before Dusk's sortition counts it at all. $DUSK
third, and this is the one i almost missed: penalization. i found that repeated faults don't just cost rewards — each consecutive suspension moves an escalating percentage of stake into the claimable rewards pool, starting at 10% and climbing 10% with every subsequent violation.
i traced what happens when that penalization pushes a stake below the 1000 DUSK floor. it doesn't just lose weight in sortition. i found it gets frozen outright — the only way back on Dusk is unstaking the frozen remainder and restaking fresh.
so eligibility isn't a single gate a provisioner passes through once. it's three separate mechanisms — a floor, a clock, and a penalty schedule — any one of which can quietly disqualify a Dusk provisioner who thought they were still active. #dusk
does layering eligibility across three independent mechanisms make Dusk more resistant to gaming, or does it just make it easier for an honest provisioner to lose status without immediately realizing why?
#dusk $DUSK @Dusk
it's actually three separate mechanisms working together, and any one of them can take it away.
first: the minimum stake. i confirmed a Dusk provisioner needs 1000 DUSK locked, and below that threshold, nothing else about the stake matters.
second: maturity. even a stake above the minimum has to sit through a fixed number of epochs before Dusk's sortition counts it at all. $DUSK
third, and this is the one i almost missed: penalization. i found that repeated faults don't just cost rewards — each consecutive suspension moves an escalating percentage of stake into the claimable rewards pool, starting at 10% and climbing 10% with every subsequent violation.
i traced what happens when that penalization pushes a stake below the 1000 DUSK floor. it doesn't just lose weight in sortition. i found it gets frozen outright — the only way back on Dusk is unstaking the frozen remainder and restaking fresh.
so eligibility isn't a single gate a provisioner passes through once. it's three separate mechanisms — a floor, a clock, and a penalty schedule — any one of which can quietly disqualify a Dusk provisioner who thought they were still active. #dusk
does layering eligibility across three independent mechanisms make Dusk more resistant to gaming, or does it just make it easier for an honest provisioner to lose status without immediately realizing why?
#dusk $DUSK @Dusk
More resistant
100%
Easy to lose status
0%
3 Votes • Vote fermé
Dusk is building around a problem that transparent blockchains cannot always solve efficiently.
precious Zarmalaa
·
--
DUSK's Two Transaction Models, Moonlight and Phoenix
I was checking a simple transfer flow on Dusk's testnet this evening, switching between a public wallet view and a shielded one for the same test amount. The public side showed everything immediately, sender, recipient, amount. The shielded side showed almost nothing.
I assumed that was just two display modes for the same underlying transaction. That felt reasonable at first.
I was wrong. Moonlight is account-based. Balances sit in the open, and a transfer exposes sender, recipient, and amount by default. Phoenix works differently. Funds sit as encrypted notes instead. There's a zero-knowledge proof behind it that just confirms the transaction checks out, nothing about the amount, the sender, or which notes got spent actually shows up.
Two different transaction models, not two views of one model, and that distinction is the whole point of comparing them at all.
What I kept circling back to, after closing the laptop and coming back to it, is that both still settle through the same place on Dusk. DuskDS handles both. The Transfer Contract accepts either payload type and routes it through the matching verification logic, keeping the network's global state consistent either way.
The choice between Moonlight and Phoenix isn't about which chain to use. It's a choice made per transaction, inside one settlement layer, about how much the rest of the network gets to see.
I still don't know how often builders default to one model over the other when a workflow doesn't strictly require privacy.
If a wallet let you choose per transaction, which model would you reach for by default?
@Dusk #dusk $DUSK #dusk
I was checking a simple transfer flow on Dusk's testnet this evening, switching between a public wallet view and a shielded one for the same test amount. The public side showed everything immediately, sender, recipient, amount. The shielded side showed almost nothing.
I assumed that was just two display modes for the same underlying transaction. That felt reasonable at first.
I was wrong. Moonlight is account-based. Balances sit in the open, and a transfer exposes sender, recipient, and amount by default. Phoenix works differently. Funds sit as encrypted notes instead. There's a zero-knowledge proof behind it that just confirms the transaction checks out, nothing about the amount, the sender, or which notes got spent actually shows up.
Two different transaction models, not two views of one model, and that distinction is the whole point of comparing them at all.
What I kept circling back to, after closing the laptop and coming back to it, is that both still settle through the same place on Dusk. DuskDS handles both. The Transfer Contract accepts either payload type and routes it through the matching verification logic, keeping the network's global state consistent either way.
The choice between Moonlight and Phoenix isn't about which chain to use. It's a choice made per transaction, inside one settlement layer, about how much the rest of the network gets to see.
I still don't know how often builders default to one model over the other when a workflow doesn't strictly require privacy.
If a wallet let you choose per transaction, which model would you reach for by default?
@Dusk #dusk $DUSK #dusk
Vérifié
#dusk $DUSK
DuskVM Compared to DuskEVM on the DUSK Network
@Dusk At first I figured picking between DuskVM and DuskEVM came down to language, Rust and WASM versus Solidity with the EVM tooling everyone's already used to. Spent longer on this tonight than expected, and somewhere in there it stopped looking like a language choice at all.
DuskVM sits right at the base of the network, so it gets straight access to the privacy and zero-knowledge stuff Dusk is actually built around. DuskEVM runs Solidity contracts through standard EVM tooling, but still settles and publishes its data back through the same DuskDS layer, paying gas in the same DUSK token either way. That's an odd symmetry I keep coming back to, different execution paths, same settlement, same token underneath both.
Choosing DuskVM isn't just choosing a language, it's choosing proximity to the privacy primitives themselves. Choosing DuskEVM isn't just familiarity, it's distance from those primitives for tooling most developers already know. That's a subtle friction most comparisons skip past. #dusk
There's a third layer under both that I keep landing back on. Dusk's docs confirm DuskEVM lets existing EVM wallets, bridges, and exchanges plug in with barely any code changes, quicker than a native integration would take. DuskVM offers no equivalent shortcut. Tooling has to be built for it, from nothing, every time. $DUSK
Feature parity between the two isn't guaranteed just because both settle through the same layer and share a gas token. What looks like optionality on the surface is really two different bets on where the actual cost gets paid, up front in tooling, or later in what the environment can't do.
Is Dusk actually offering builders a choice here, or just deciding for them where the friction shows up? @Dusk
DuskVM Compared to DuskEVM on the DUSK Network
@Dusk At first I figured picking between DuskVM and DuskEVM came down to language, Rust and WASM versus Solidity with the EVM tooling everyone's already used to. Spent longer on this tonight than expected, and somewhere in there it stopped looking like a language choice at all.
DuskVM sits right at the base of the network, so it gets straight access to the privacy and zero-knowledge stuff Dusk is actually built around. DuskEVM runs Solidity contracts through standard EVM tooling, but still settles and publishes its data back through the same DuskDS layer, paying gas in the same DUSK token either way. That's an odd symmetry I keep coming back to, different execution paths, same settlement, same token underneath both.
Choosing DuskVM isn't just choosing a language, it's choosing proximity to the privacy primitives themselves. Choosing DuskEVM isn't just familiarity, it's distance from those primitives for tooling most developers already know. That's a subtle friction most comparisons skip past. #dusk
There's a third layer under both that I keep landing back on. Dusk's docs confirm DuskEVM lets existing EVM wallets, bridges, and exchanges plug in with barely any code changes, quicker than a native integration would take. DuskVM offers no equivalent shortcut. Tooling has to be built for it, from nothing, every time. $DUSK
Feature parity between the two isn't guaranteed just because both settle through the same layer and share a gas token. What looks like optionality on the surface is really two different bets on where the actual cost gets paid, up front in tooling, or later in what the environment can't do.
Is Dusk actually offering builders a choice here, or just deciding for them where the friction shows up? @Dusk
#dusk $DUSK
@Dusk i used to assume a privacy chain meant every transaction was shielded by default, no exceptions.
then i read what Moonlight actually does on Dusk.
Dusk runs two native transaction models on the same settlement layer. Moonlight is account-based, public, sender and recipient and amount all visible. Phoenix is note-based, shielded, funds sitting as encrypted notes instead of a running balance, closer to spendable units than an account total. #dusk
thats the "by default" that changed how i read this, and i went back to reread that section twice just to be sure.
a single transfer picks one model or the other, never a blend. send DUSK through Moonlight and its fully transparent, built for flows that need to stay observable, some treasury or reporting scenario is the kind of example the docs point to. send it through Phoenix and the amount, the sender, and which specific notes moved all stay hidden, proven correct through zero-knowledge proofs instead of shown outright, though a viewing key can reveal that same hidden data to whoever the staker chooses to show it to. $DUSK
one Transfer Contract handles both, routing each payload to the right verification logic, keeping global state consistent either way.
so privacy here isnt binary at the protocol level either, its a choice per transfer, and even the shielded choice has a documented way to become visible again on request.
that choice sits with the sender, not the protocol.
does giving users a public option undercut the privacy pitch, or is optional, revocable privacy actually the more honest design for regulated markets?
is optional privacy still privacy?
@Dusk i used to assume a privacy chain meant every transaction was shielded by default, no exceptions.
then i read what Moonlight actually does on Dusk.
Dusk runs two native transaction models on the same settlement layer. Moonlight is account-based, public, sender and recipient and amount all visible. Phoenix is note-based, shielded, funds sitting as encrypted notes instead of a running balance, closer to spendable units than an account total. #dusk
thats the "by default" that changed how i read this, and i went back to reread that section twice just to be sure.
a single transfer picks one model or the other, never a blend. send DUSK through Moonlight and its fully transparent, built for flows that need to stay observable, some treasury or reporting scenario is the kind of example the docs point to. send it through Phoenix and the amount, the sender, and which specific notes moved all stay hidden, proven correct through zero-knowledge proofs instead of shown outright, though a viewing key can reveal that same hidden data to whoever the staker chooses to show it to. $DUSK
one Transfer Contract handles both, routing each payload to the right verification logic, keeping global state consistent either way.
so privacy here isnt binary at the protocol level either, its a choice per transfer, and even the shielded choice has a documented way to become visible again on request.
that choice sits with the sender, not the protocol.
does giving users a public option undercut the privacy pitch, or is optional, revocable privacy actually the more honest design for regulated markets?
is optional privacy still privacy?
Connectez-vous pour découvrir plus de contenu