Luke_龙
609 Публикации
Luke_龙
No Bio Because I Don't Care.😎🤷
150 подписок(и/а)
5.5K+ подписчиков(а)
1.2K+ понравилось
Посты
Все
Цитирования
Активно
PINNED
Торговля за 30 дней $BTC 317.5 USDT
🧧 Red Packet drop — and the market's giving us plenty to talk about
BTC is holding near $79K after touching $81K earlier this week, cooling off a bit as traders took profits ahead of Jackson Hole. ETH climbed back above $2,500, and $SOL had the standout day, up nearly 6%. BlackRock's also been pulling in big inflows on its Bitcoin and Ethereum ETFs — momentum isn't slowing down.
Wherever this market goes next, thank you for following along and being part of the conversation here 🙏
Dropping a Red Packet as a small thank-you 🎁
✅ Follow for daily market updates
✅ Like + comment your take on where BTC my heads next
🍀 Good luck to everyone who grabs one
Let's keep watching this market together 🚀
$BTC $ETH
#BinanceSquare #redpacket #bitcoin #CryptoNews
BTC is holding near $79K after touching $81K earlier this week, cooling off a bit as traders took profits ahead of Jackson Hole. ETH climbed back above $2,500, and $SOL had the standout day, up nearly 6%. BlackRock's also been pulling in big inflows on its Bitcoin and Ethereum ETFs — momentum isn't slowing down.
Wherever this market goes next, thank you for following along and being part of the conversation here 🙏
Dropping a Red Packet as a small thank-you 🎁
✅ Follow for daily market updates
✅ Like + comment your take on where BTC my heads next
🍀 Good luck to everyone who grabs one
Let's keep watching this market together 🚀
$BTC $ETH
#BinanceSquare #redpacket #bitcoin #CryptoNews
PINNED
Частичная правда
Торговля за 30 дней $DUSK 52 USDT
#dusk $DUSK @Dusk
Read the peer-to-peer section of the whitepaper twice this week.
First pass, filed it as boring plumbing — how blocks get broadcast, not worth dwelling on. Second pass, I'd been wrong about what Kadcast is actually optimizing for.
I'd been treating 'efficient broadcast' and private broadcast as two separate wins bundled together for marketing convenience. They're not separate. One is a side effect of the other.
Kadcast doesn't flood messages to every neighboring node like gossip protocols do. It uses XOR distance from Kademlia's DHT to structure propagation — each node forwards only to peers at increasing distances, so the message cascades outward instead of blasting everywhere at once.
The whitepaper cites 25-50% less bandwidth than gossip protocols, and 10-30% fewer stale blocks in fast-block networks, because fewer redundant transmissions means fewer wasted validations on blocks that never make it into the chain.
Here's the part that clicked: that exact same structure is what obscures where a message actually came from.
Because a node only ever talks to a narrow set of peers at specific distances rather than broadcasting outward to everyone, there's no single moment where the origin is visible to the whole network at once.
The privacy isn't a separate feature bolted onto the routing. It's what efficient routing looks like when you're not allowed to flood.
That's what I'd missed — Kadcast isn't fast, and also private.
It's private because it's the specific kind of fast that doesn't require exposing the source to get there.
Two things I'm still turning over: does structured, distance-based routing create a different kind of attack surface than gossip does — predictable paths versus unpredictable flooding — even if it's harder to trace origin? And do the bandwidth and stale-block numbers in the whitepaper reflect Dusk's actual network in production, or are they still the general Kadcast research being cited rather than Dusk-specific measurements?
$DUSK
Read the peer-to-peer section of the whitepaper twice this week.
First pass, filed it as boring plumbing — how blocks get broadcast, not worth dwelling on. Second pass, I'd been wrong about what Kadcast is actually optimizing for.
I'd been treating 'efficient broadcast' and private broadcast as two separate wins bundled together for marketing convenience. They're not separate. One is a side effect of the other.
Kadcast doesn't flood messages to every neighboring node like gossip protocols do. It uses XOR distance from Kademlia's DHT to structure propagation — each node forwards only to peers at increasing distances, so the message cascades outward instead of blasting everywhere at once.
The whitepaper cites 25-50% less bandwidth than gossip protocols, and 10-30% fewer stale blocks in fast-block networks, because fewer redundant transmissions means fewer wasted validations on blocks that never make it into the chain.
Here's the part that clicked: that exact same structure is what obscures where a message actually came from.
Because a node only ever talks to a narrow set of peers at specific distances rather than broadcasting outward to everyone, there's no single moment where the origin is visible to the whole network at once.
The privacy isn't a separate feature bolted onto the routing. It's what efficient routing looks like when you're not allowed to flood.
That's what I'd missed — Kadcast isn't fast, and also private.
It's private because it's the specific kind of fast that doesn't require exposing the source to get there.
Two things I'm still turning over: does structured, distance-based routing create a different kind of attack surface than gossip does — predictable paths versus unpredictable flooding — even if it's harder to trace origin? And do the bandwidth and stale-block numbers in the whitepaper reflect Dusk's actual network in production, or are they still the general Kadcast research being cited rather than Dusk-specific measurements?
$DUSK
$RIVER #long
tp 1.581
sl 1.55
entry 1.562.
it just broke it's previous high at 1.565. next stop starts at tp
tp 1.581
sl 1.55
entry 1.562.
it just broke it's previous high at 1.565. next stop starts at tp
go claim 🧧, @x_Trader_
x_Trader_
·
--
🧧Have a Good Day Everyone 🧧
Repost ✅
Claim Free Crypto tokens+ coins...✅🎉
@YUGEN优恩 @x_Rex
Repost ✅
Claim Free Crypto tokens+ coins...✅🎉
@YUGEN优恩 @x_Rex
go claim🧧 @x_Rex
x_Rex
·
--
🧧 Happy Friday, everyone 🧧
Repost✅, + Claim✅
Type 👉 blessing .
Not gonna pretend today was easy, it wasn't. red days happen to all of us, and today hit harder than most. but Fridays have a way of resetting something in me, so here's a small red packet to pass a little good luck around.
First come first served.
Whatever kind of week you had, I hope your Friday is softer than mine was. we go again.
Repost✅, + Claim✅
Type 👉 blessing .
Not gonna pretend today was easy, it wasn't. red days happen to all of us, and today hit harder than most. but Fridays have a way of resetting something in me, so here's a small red packet to pass a little good luck around.
First come first served.
Whatever kind of week you had, I hope your Friday is softer than mine was. we go again.
$JCT bounced off $0.0016 and has been chopping between $0.0018-0.0023 since.
Just got rejected near $0.0022, sliding back toward $0.0021 where the short-term averages are stacked. Buyers defended the low, but every push higher in this range keeps getting sold into.
Levels:
Support: $0.0019-0.0020
Resistance: $0.0022-0.0023
Lose $0.0019 and this bounce is probably done. Clear $0.0023 with volume and it starts looking like an actual floor.
Down 48.5% over 30 days — this is a pause, not a confirmed reversal yet.
Floor forming, or one more leg down? 👇
Markets are highly volatile so prices may vary by the time you read this. Not financial advice. DYOR 🙏
$JCT
Just got rejected near $0.0022, sliding back toward $0.0021 where the short-term averages are stacked. Buyers defended the low, but every push higher in this range keeps getting sold into.
Levels:
Support: $0.0019-0.0020
Resistance: $0.0022-0.0023
Lose $0.0019 and this bounce is probably done. Clear $0.0023 with volume and it starts looking like an actual floor.
Down 48.5% over 30 days — this is a pause, not a confirmed reversal yet.
Floor forming, or one more leg down? 👇
Markets are highly volatile so prices may vary by the time you read this. Not financial advice. DYOR 🙏
$JCT
The part I keep coming back to is the trade-off between WASM isolation and native cryptographic performance. Dusk isn't simply making ZK verification faster; it's deciding which operations belong inside the smart-contract sandbox and which should be handled by the host.
That choice could matter a lot once confidential transactions are running at real scale. I’d be interested to see actual Piecrust benchmarks for PLONK/Groth16 verification, not just the general WASM performance research.
#dusk $DUSK
That choice could matter a lot once confidential transactions are running at real scale. I’d be interested to see actual Piecrust benchmarks for PLONK/Groth16 verification, not just the general WASM performance research.
#dusk $DUSK
Luke_龙
·
--
#dusk $DUSK @Dusk
Read the peer-to-peer section of the whitepaper twice this week.
First pass, filed it as boring plumbing — how blocks get broadcast, not worth dwelling on. Second pass, I'd been wrong about what Kadcast is actually optimizing for.
I'd been treating 'efficient broadcast' and private broadcast as two separate wins bundled together for marketing convenience. They're not separate. One is a side effect of the other.
Kadcast doesn't flood messages to every neighboring node like gossip protocols do. It uses XOR distance from Kademlia's DHT to structure propagation — each node forwards only to peers at increasing distances, so the message cascades outward instead of blasting everywhere at once.
The whitepaper cites 25-50% less bandwidth than gossip protocols, and 10-30% fewer stale blocks in fast-block networks, because fewer redundant transmissions means fewer wasted validations on blocks that never make it into the chain.
Here's the part that clicked: that exact same structure is what obscures where a message actually came from.
Because a node only ever talks to a narrow set of peers at specific distances rather than broadcasting outward to everyone, there's no single moment where the origin is visible to the whole network at once.
The privacy isn't a separate feature bolted onto the routing. It's what efficient routing looks like when you're not allowed to flood.
That's what I'd missed — Kadcast isn't fast, and also private.
It's private because it's the specific kind of fast that doesn't require exposing the source to get there.
Two things I'm still turning over: does structured, distance-based routing create a different kind of attack surface than gossip does — predictable paths versus unpredictable flooding — even if it's harder to trace origin? And do the bandwidth and stale-block numbers in the whitepaper reflect Dusk's actual network in production, or are they still the general Kadcast research being cited rather than Dusk-specific measurements?
$DUSK
Read the peer-to-peer section of the whitepaper twice this week.
First pass, filed it as boring plumbing — how blocks get broadcast, not worth dwelling on. Second pass, I'd been wrong about what Kadcast is actually optimizing for.
I'd been treating 'efficient broadcast' and private broadcast as two separate wins bundled together for marketing convenience. They're not separate. One is a side effect of the other.
Kadcast doesn't flood messages to every neighboring node like gossip protocols do. It uses XOR distance from Kademlia's DHT to structure propagation — each node forwards only to peers at increasing distances, so the message cascades outward instead of blasting everywhere at once.
The whitepaper cites 25-50% less bandwidth than gossip protocols, and 10-30% fewer stale blocks in fast-block networks, because fewer redundant transmissions means fewer wasted validations on blocks that never make it into the chain.
Here's the part that clicked: that exact same structure is what obscures where a message actually came from.
Because a node only ever talks to a narrow set of peers at specific distances rather than broadcasting outward to everyone, there's no single moment where the origin is visible to the whole network at once.
The privacy isn't a separate feature bolted onto the routing. It's what efficient routing looks like when you're not allowed to flood.
That's what I'd missed — Kadcast isn't fast, and also private.
It's private because it's the specific kind of fast that doesn't require exposing the source to get there.
Two things I'm still turning over: does structured, distance-based routing create a different kind of attack surface than gossip does — predictable paths versus unpredictable flooding — even if it's harder to trace origin? And do the bandwidth and stale-block numbers in the whitepaper reflect Dusk's actual network in production, or are they still the general Kadcast research being cited rather than Dusk-specific measurements?
$DUSK
$BTC just touched $80K for the first time since mid-May before pulling back to trade around $79,300. Wild part isn't even the price, it's the move — up roughly 28% just this month, driven less by crypto-specific news and more by Treasury bond buybacks easing yields and a wave of short liquidations forcing bears to cover.
Fear & Greed Index is sitting at 74 (Greed), up from 41 just last week — sentiment flipped faster than most people repositioned.
Still well off the October peak near $126K, so this is a recovery move, not new highs. Worth watching if $80K holds as support or turns into resistance again
Not financial advice, just tracking the tape.
$BTC
Fear & Greed Index is sitting at 74 (Greed), up from 41 just last week — sentiment flipped faster than most people repositioned.
Still well off the October peak near $126K, so this is a recovery move, not new highs. Worth watching if $80K holds as support or turns into resistance again
Not financial advice, just tracking the tape.
$BTC
Проверено
Холдинг $DUSK 10.6 USDT
#dusk $DUSK
Kept writing about Dusk's pieces as five separate threads, DuskEVM, the EU partnerships, the privacy model, native issuance, whatever come up that week.
Went back through everything I've posted and realized I'd never actually laid out why they are not five projects, But one build order.
So @Dusk
DuskEVM and Hedger are the execution layer, an EVM-compatible environment institutions and developers already know, with confidential transaction support built in through homomorphic encryption plus ZK proofs,and not bolted on after
The EU-licensed partnerships, NPEX, Chainlink, are the legitimacy layer.
NPEX alone plans to bring over 300M EUR in assets on-chain, but that number means nothing without a regulated venue actually willing to settle through Dusk in the first place.
Programmable privacy is the design principle threading through both:
privacy where it's needed, transparency where it's useful, selective disclosure for whoever's authorized to look.
Not a feature, a constraint every other piece has to satisfy.
Native issuance is the asset model-the difference between wrapping an existing off-chain bond and actually building one on-chain, ownership through settlement, as one record instead of six reconciling systems.
Four pillars.
Each one, on its own, is infrastructure.
None of them, alone, is something an actual investor ever touches.
That's what Dusk Trade is for.
It's not a fifth pillar sitting next to the other four — it's the application layer sitting on top of all of them.
Confidential execution Hedger, regulatory legitimacy from the NPEX-style partnerships, the privacy model governing what's disclosed and to whom, native-issued assets as the actual inventory being traded. Remove any one of the four and Dusk Trade isn't a regulated venue, it's just another interface.
All I got from Whitepaper.
But does bundling four hard problems into one front-facing product make Dusk Trade the strongest case for the whole stack, or the single point where all four have to work perfectly at once for any of it to matter?
Kept writing about Dusk's pieces as five separate threads, DuskEVM, the EU partnerships, the privacy model, native issuance, whatever come up that week.
Went back through everything I've posted and realized I'd never actually laid out why they are not five projects, But one build order.
So @Dusk
DuskEVM and Hedger are the execution layer, an EVM-compatible environment institutions and developers already know, with confidential transaction support built in through homomorphic encryption plus ZK proofs,and not bolted on after
The EU-licensed partnerships, NPEX, Chainlink, are the legitimacy layer.
NPEX alone plans to bring over 300M EUR in assets on-chain, but that number means nothing without a regulated venue actually willing to settle through Dusk in the first place.
Programmable privacy is the design principle threading through both:
privacy where it's needed, transparency where it's useful, selective disclosure for whoever's authorized to look.
Not a feature, a constraint every other piece has to satisfy.
Native issuance is the asset model-the difference between wrapping an existing off-chain bond and actually building one on-chain, ownership through settlement, as one record instead of six reconciling systems.
Four pillars.
Each one, on its own, is infrastructure.
None of them, alone, is something an actual investor ever touches.
That's what Dusk Trade is for.
It's not a fifth pillar sitting next to the other four — it's the application layer sitting on top of all of them.
Confidential execution Hedger, regulatory legitimacy from the NPEX-style partnerships, the privacy model governing what's disclosed and to whom, native-issued assets as the actual inventory being traded. Remove any one of the four and Dusk Trade isn't a regulated venue, it's just another interface.
All I got from Whitepaper.
But does bundling four hard problems into one front-facing product make Dusk Trade the strongest case for the whole stack, or the single point where all four have to work perfectly at once for any of it to matter?
Проверено
Торговля за 30 дней $DUSK 30.1 USDT
#dusk
Realized I've written the phrase zero-knowledge proof in probably eight different posts now without ever once explaining what's actually computing them.
Went looking for the actual cryptographic primitives behind it instead of just gesturing at the term again.
Turns out it's not one piece of math doing everything. It's four, each handling a different job.
BLS12-381 is the elliptic curve underneath the signature and proof system.
It's pairing-friendly, which is the specific property that makes aggregating signatures and building succinct proofs practical instead of computationally brutal.
JubJub is a separate curve, optimized specifically to run efficiently inside SNARK circuits, which is where Phoenix's shielded notes actually get their privacy proven.
Poseidon is the hash function doing the heavy lifting inside those circuits.
Regular hash functions like SHA-256 are fine for normal use but expensive to compute inside a zero-knowledge proof.
Poseidon is built specifically to be cheap in that context, which is why it shows up for commitments and Merkle tree hashing instead of something more familiar.
PLONK is the part that actually turns all of this into a provable statement.
It's the proving system, the thing that lets a developer define a circuit once and generate proofs that get verified on-chain without redoing the original computation.
What struck me putting these together: none of them are Dusk-specific inventions.
They're established cryptographic building blocks, chosen and assembled for a specific job.
The actual engineering decision was picking the right combination, not inventing new math from scratch.
$DUSK
So, @Dusk .
Does using established, heavily studied primitives instead of novel cryptography make a privacy chain more trustworthy, or does stacking four different systems together just create new failure points at the seams? And does an average person using any of this ever need to know a single one of these names, or is this permanently backstage, mattering only to auditors and researchers?
Realized I've written the phrase zero-knowledge proof in probably eight different posts now without ever once explaining what's actually computing them.
Went looking for the actual cryptographic primitives behind it instead of just gesturing at the term again.
Turns out it's not one piece of math doing everything. It's four, each handling a different job.
BLS12-381 is the elliptic curve underneath the signature and proof system.
It's pairing-friendly, which is the specific property that makes aggregating signatures and building succinct proofs practical instead of computationally brutal.
JubJub is a separate curve, optimized specifically to run efficiently inside SNARK circuits, which is where Phoenix's shielded notes actually get their privacy proven.
Poseidon is the hash function doing the heavy lifting inside those circuits.
Regular hash functions like SHA-256 are fine for normal use but expensive to compute inside a zero-knowledge proof.
Poseidon is built specifically to be cheap in that context, which is why it shows up for commitments and Merkle tree hashing instead of something more familiar.
PLONK is the part that actually turns all of this into a provable statement.
It's the proving system, the thing that lets a developer define a circuit once and generate proofs that get verified on-chain without redoing the original computation.
What struck me putting these together: none of them are Dusk-specific inventions.
They're established cryptographic building blocks, chosen and assembled for a specific job.
The actual engineering decision was picking the right combination, not inventing new math from scratch.
$DUSK
So, @Dusk .
Does using established, heavily studied primitives instead of novel cryptography make a privacy chain more trustworthy, or does stacking four different systems together just create new failure points at the seams? And does an average person using any of this ever need to know a single one of these names, or is this permanently backstage, mattering only to auditors and researchers?
Проверено
Холдинг $DUSK 10.8 USDT
#dusk $DUSK @Dusk
Someone mentioned DUSK's max supply in the replies almost as a side note last week, and I realized I'd never actually looked at how emission is structured.
Just knew there was a cap somewhere.
500 million DUSK existed at genesis.
Another 500 million gets emitted over time, capped at 1 billion total, spread across 36 years.
Not a straight line either.
It decays geometrically, halving roughly every 4 years, so the early years carry a lot more new supply hitting circulation than the later ones ever will.
The reward split inside each block surprised me more than the emission curve did.
Block generator gets a fixed 70%, plus up to another 10% depending on how many committee votes actually made it into that block's certificate. Development fund takes 10%.
Validation committee splits 5%, ratification committee splits another 5%.
Here's the part I didn't expect. Whatever portion of that variable 10% doesn't get earned, because votes were missing from the certificate, doesn't roll over to anyone.
It just gets burned outright.
That's not a rounding rule.
It's an incentive.
A generator who only cares about their own reward and ignores gathering everyone's votes is quietly leaving money on the table, permanently, not redistributing it to someone else who did the work.
The design punishes sloppiness by deleting Value instead of reassigning it.
Two things I keep turning over🤔.
Does front-loading emission this heavily actually make sense for a chain aiming at long-term institutional use, or does it just mean the earliest stakers capture most of the upside before the real utility even shows up?
And does burning the unearned portion of a reward meaningfully change generator behavior in practice, or is it small enough that nobody actually adjusts what they do because of it?
🤓
Someone mentioned DUSK's max supply in the replies almost as a side note last week, and I realized I'd never actually looked at how emission is structured.
Just knew there was a cap somewhere.
500 million DUSK existed at genesis.
Another 500 million gets emitted over time, capped at 1 billion total, spread across 36 years.
Not a straight line either.
It decays geometrically, halving roughly every 4 years, so the early years carry a lot more new supply hitting circulation than the later ones ever will.
The reward split inside each block surprised me more than the emission curve did.
Block generator gets a fixed 70%, plus up to another 10% depending on how many committee votes actually made it into that block's certificate. Development fund takes 10%.
Validation committee splits 5%, ratification committee splits another 5%.
Here's the part I didn't expect. Whatever portion of that variable 10% doesn't get earned, because votes were missing from the certificate, doesn't roll over to anyone.
It just gets burned outright.
That's not a rounding rule.
It's an incentive.
A generator who only cares about their own reward and ignores gathering everyone's votes is quietly leaving money on the table, permanently, not redistributing it to someone else who did the work.
The design punishes sloppiness by deleting Value instead of reassigning it.
Two things I keep turning over🤔.
Does front-loading emission this heavily actually make sense for a chain aiming at long-term institutional use, or does it just mean the earliest stakers capture most of the upside before the real utility even shows up?
And does burning the unearned portion of a reward meaningfully change generator behavior in practice, or is it small enough that nobody actually adjusts what they do because of it?
🤓
Проверено
Торговля за 30 дней $DUSK 22.7 USDT
#dusk $DUSK @Dusk
I wasn't surprised when one of my Binance friend told me.
'Dusk partnered with Quantoz Payments to bring EURQ, a MiCA-compliant digital euro, onto the network.'
I only sat down with what that actually means this week since that discussion, going back through announcements from earlier in the year I'd skimmed past the first time because I thought it to be another fake info to create hype.
But I was wrong.
Most things people call "stablecoins" aren't legally money.
They're a synthetic peg, backed by whatever reserve the issuer claims he has, believing hoping it holds. EURQ isn't that.
It's classified as an Electronic Money Token under MiCA.
A specific, defined category suitable for use as legal tender, not just a trading instrument sitting near one euro.
That distinction matters most for who actually needs it. NPEX is a regulated exchange. "Settled in a token that might depeg overnight" isn't an acceptable answer there, no matter how solid the peg has looked historically.
They need something that's actually, legally, a euro.
Dusk is one of three chains where EURQ works, and the only one built specifically for native RWA issuance with compliance already part of the design.
The part that connects even further than expected: Quantoz mints EURQ, it moves through Dusk, NPEX settles trades with it, and the same rail feeds Dusk Pay.
The payment system for everyday transactions, not just Investor Settlement.
A euro that works for a stock trade is the same euro that could work for buying coffee.
Once actual money moves through a chain instead of a synthetic stand-in for it, separate use cases start being the same rail used differently.
Some of you are still circling and wondering like me.
Does the EMT classification actually change user behavior day to day, or does it mostly matter at the compliance layer, invisible to anyone just holding it?
I wasn't surprised when one of my Binance friend told me.
'Dusk partnered with Quantoz Payments to bring EURQ, a MiCA-compliant digital euro, onto the network.'
I only sat down with what that actually means this week since that discussion, going back through announcements from earlier in the year I'd skimmed past the first time because I thought it to be another fake info to create hype.
But I was wrong.
Most things people call "stablecoins" aren't legally money.
They're a synthetic peg, backed by whatever reserve the issuer claims he has, believing hoping it holds. EURQ isn't that.
It's classified as an Electronic Money Token under MiCA.
A specific, defined category suitable for use as legal tender, not just a trading instrument sitting near one euro.
That distinction matters most for who actually needs it. NPEX is a regulated exchange. "Settled in a token that might depeg overnight" isn't an acceptable answer there, no matter how solid the peg has looked historically.
They need something that's actually, legally, a euro.
Dusk is one of three chains where EURQ works, and the only one built specifically for native RWA issuance with compliance already part of the design.
The part that connects even further than expected: Quantoz mints EURQ, it moves through Dusk, NPEX settles trades with it, and the same rail feeds Dusk Pay.
The payment system for everyday transactions, not just Investor Settlement.
A euro that works for a stock trade is the same euro that could work for buying coffee.
Once actual money moves through a chain instead of a synthetic stand-in for it, separate use cases start being the same rail used differently.
Some of you are still circling and wondering like me.
Does the EMT classification actually change user behavior day to day, or does it mostly matter at the compliance layer, invisible to anyone just holding it?
Проверено
Холдинг $DUSK 10.7 USDT
#dusk
My Brother who is also my trading mentor told me that compliant infrastructure isn't the same thing as a product. And I've thought about it a lot and finally realized.
That's the part I keep seeing skipped in RWA conversations.
A chain can have perfect consensus, airtight privacy, verified oracle data, and still be useless to an actual investor if there's no front door. Dusk Trade is that front door.
It's the application layer for tokenized financial assets on DuskEVM, structured to operate as a regulated MTF and investment platform under EU rules, not a wrapper bolted on after the fact.
MMFs, ETFs, Bonds, and other RWAs live here, and the whole point is that owning one of these assets works like actually owning it.
You settle instantly instead of waiting T+2, and the position still composes with DeFi the way any other on-chain asset would.
Here's the thing that took me a minute to connect.
Every post I've written about this chain, the consensus mechanics, Hedger, the Chainlink data feeds, none of that is the product.
It's the engine.
Nobody buys a car for the engine spec sheet. They buy it because it takes them somewhere. Dusk Trade is the "somewhere" for everything else in this stack.
Onboarding, wallet connection, buying, selling, settlement coordination, it's where eligibility checks and privacy and deterministic finality stop being protocol features and start being a screen someone actually taps through😃.
What I find genuinely underrated about this is the composability angle🙂.
Most regulated platforms bury an asset the moment it's tokenized.
You can hold it, maybe trade it on their venue, and that's it🤷.
DeFi-grade composability means the asset doesn't get stuck the second it's compliant. That's a real tension most projects don't solve, they pick one side.
There is still an question that I'm curious about:
Does 'regulated and composable' actually hold up once volume shows up!?
Or
Does one side always end up winning out under real market stress!?
$DUSK @Dusk
My Brother who is also my trading mentor told me that compliant infrastructure isn't the same thing as a product. And I've thought about it a lot and finally realized.
That's the part I keep seeing skipped in RWA conversations.
A chain can have perfect consensus, airtight privacy, verified oracle data, and still be useless to an actual investor if there's no front door. Dusk Trade is that front door.
It's the application layer for tokenized financial assets on DuskEVM, structured to operate as a regulated MTF and investment platform under EU rules, not a wrapper bolted on after the fact.
MMFs, ETFs, Bonds, and other RWAs live here, and the whole point is that owning one of these assets works like actually owning it.
You settle instantly instead of waiting T+2, and the position still composes with DeFi the way any other on-chain asset would.
Here's the thing that took me a minute to connect.
Every post I've written about this chain, the consensus mechanics, Hedger, the Chainlink data feeds, none of that is the product.
It's the engine.
Nobody buys a car for the engine spec sheet. They buy it because it takes them somewhere. Dusk Trade is the "somewhere" for everything else in this stack.
Onboarding, wallet connection, buying, selling, settlement coordination, it's where eligibility checks and privacy and deterministic finality stop being protocol features and start being a screen someone actually taps through😃.
What I find genuinely underrated about this is the composability angle🙂.
Most regulated platforms bury an asset the moment it's tokenized.
You can hold it, maybe trade it on their venue, and that's it🤷.
DeFi-grade composability means the asset doesn't get stuck the second it's compliant. That's a real tension most projects don't solve, they pick one side.
There is still an question that I'm curious about:
Does 'regulated and composable' actually hold up once volume shows up!?
Or
Does one side always end up winning out under real market stress!?
$DUSK @Dusk
Genuine question — does Chainlink's data feed itself become confidential on Dusk, or is the privacy only on the transaction side? Feels like that matters for the argument.
#dusk $DUSK
#dusk $DUSK
Luke_龙
·
--
#dusk $DUSK
Everyone talks about RWA tokenization like the hard part is getting the asset on-chain. It's not. The hard part is what happens after: the asset still needs to know things about the outside world it can't see for itself.
A tokenized bond needs to know if the issuer defaulted. A fund needs its NAV updated daily. A settlement contract needs to know if payment actually cleared offchain, in a bank system that has nothing to do with blockchains. None of that lives on-chain by default. It has to come from somewhere, and that "somewhere" is usually the weakest link in the whole design. A contract is only as trustworthy as the data someone feeds it.
This is where Chainlink fits into what@Dusk
is building. Not as a headline feature, more like plumbing.
Dusk's partnership with Chainlink brings verified external data onto the network, so contracts can act on real-world events without just trusting whoever happens to submit the update.
That sounds like a small detail until you think about what it's actually replacing,a human, or a single centralized feed, being the sole source of truth for a financial instrument worth real money.
The part I keep turning over is that privacy and correct data are actually the same problem wearing different clothes.
Confidential balances don't mean much if the price feed or default status behind them is wrong or manipulated in the first place.
You can build the most airtight ZK proof in the world, and it still only proves the math was done correctly on whatever number it was fed.
Junk in, provably verified junk out.
I hadn't thought about oracle infrastructure as a "privacy problem" before, honestly.
I'd filed it under boring back-end plumbing.
But once you connect it to everything Dusk is doing with Hedger and selective disclosure, it stops feeling separate.
Confidentiality on the transaction side means nothing if the Inputs feeding the contract are sitting on a weak link.
The real RWA question isn't , Privacy.
It's trust.
Who is telling the contract the truth, and can you verify it?
Everyone talks about RWA tokenization like the hard part is getting the asset on-chain. It's not. The hard part is what happens after: the asset still needs to know things about the outside world it can't see for itself.
A tokenized bond needs to know if the issuer defaulted. A fund needs its NAV updated daily. A settlement contract needs to know if payment actually cleared offchain, in a bank system that has nothing to do with blockchains. None of that lives on-chain by default. It has to come from somewhere, and that "somewhere" is usually the weakest link in the whole design. A contract is only as trustworthy as the data someone feeds it.
This is where Chainlink fits into what@Dusk
is building. Not as a headline feature, more like plumbing.
Dusk's partnership with Chainlink brings verified external data onto the network, so contracts can act on real-world events without just trusting whoever happens to submit the update.
That sounds like a small detail until you think about what it's actually replacing,a human, or a single centralized feed, being the sole source of truth for a financial instrument worth real money.
The part I keep turning over is that privacy and correct data are actually the same problem wearing different clothes.
Confidential balances don't mean much if the price feed or default status behind them is wrong or manipulated in the first place.
You can build the most airtight ZK proof in the world, and it still only proves the math was done correctly on whatever number it was fed.
Junk in, provably verified junk out.
I hadn't thought about oracle infrastructure as a "privacy problem" before, honestly.
I'd filed it under boring back-end plumbing.
But once you connect it to everything Dusk is doing with Hedger and selective disclosure, it stops feeling separate.
Confidentiality on the transaction side means nothing if the Inputs feeding the contract are sitting on a weak link.
The real RWA question isn't , Privacy.
It's trust.
Who is telling the contract the truth, and can you verify it?
Проверено
#dusk $DUSK
Everyone talks about RWA tokenization like the hard part is getting the asset on-chain. It's not. The hard part is what happens after: the asset still needs to know things about the outside world it can't see for itself.
A tokenized bond needs to know if the issuer defaulted. A fund needs its NAV updated daily. A settlement contract needs to know if payment actually cleared offchain, in a bank system that has nothing to do with blockchains. None of that lives on-chain by default. It has to come from somewhere, and that "somewhere" is usually the weakest link in the whole design. A contract is only as trustworthy as the data someone feeds it.
This is where Chainlink fits into what@Dusk
is building. Not as a headline feature, more like plumbing.
Dusk's partnership with Chainlink brings verified external data onto the network, so contracts can act on real-world events without just trusting whoever happens to submit the update.
That sounds like a small detail until you think about what it's actually replacing,a human, or a single centralized feed, being the sole source of truth for a financial instrument worth real money.
The part I keep turning over is that privacy and correct data are actually the same problem wearing different clothes.
Confidential balances don't mean much if the price feed or default status behind them is wrong or manipulated in the first place.
You can build the most airtight ZK proof in the world, and it still only proves the math was done correctly on whatever number it was fed.
Junk in, provably verified junk out.
I hadn't thought about oracle infrastructure as a "privacy problem" before, honestly.
I'd filed it under boring back-end plumbing.
But once you connect it to everything Dusk is doing with Hedger and selective disclosure, it stops feeling separate.
Confidentiality on the transaction side means nothing if the Inputs feeding the contract are sitting on a weak link.
The real RWA question isn't , Privacy.
It's trust.
Who is telling the contract the truth, and can you verify it?
Everyone talks about RWA tokenization like the hard part is getting the asset on-chain. It's not. The hard part is what happens after: the asset still needs to know things about the outside world it can't see for itself.
A tokenized bond needs to know if the issuer defaulted. A fund needs its NAV updated daily. A settlement contract needs to know if payment actually cleared offchain, in a bank system that has nothing to do with blockchains. None of that lives on-chain by default. It has to come from somewhere, and that "somewhere" is usually the weakest link in the whole design. A contract is only as trustworthy as the data someone feeds it.
This is where Chainlink fits into what@Dusk
is building. Not as a headline feature, more like plumbing.
Dusk's partnership with Chainlink brings verified external data onto the network, so contracts can act on real-world events without just trusting whoever happens to submit the update.
That sounds like a small detail until you think about what it's actually replacing,a human, or a single centralized feed, being the sole source of truth for a financial instrument worth real money.
The part I keep turning over is that privacy and correct data are actually the same problem wearing different clothes.
Confidential balances don't mean much if the price feed or default status behind them is wrong or manipulated in the first place.
You can build the most airtight ZK proof in the world, and it still only proves the math was done correctly on whatever number it was fed.
Junk in, provably verified junk out.
I hadn't thought about oracle infrastructure as a "privacy problem" before, honestly.
I'd filed it under boring back-end plumbing.
But once you connect it to everything Dusk is doing with Hedger and selective disclosure, it stops feeling separate.
Confidentiality on the transaction side means nothing if the Inputs feeding the contract are sitting on a weak link.
The real RWA question isn't , Privacy.
It's trust.
Who is telling the contract the truth, and can you verify it?
Холдинг $DUSK 10.4 USDT
#dusk got me really curious about Zero-Knowledge Compliance. Sounded interesting to me so I went and read about it myself. And a lot of questions popped up afterwards .
$DUSK
Have you ever placed a trade. Then someone else quickly jumps in front of you? Have you ever thought it was bad luck?
Then I found the actual problem, reading through Dusk's official docs. My orders were fully transparent before they even settled. Visible to everyone. Wasn't a glitch. Someone was just watching them 🙁
@Dusk 's approach to this problem is what made me figure it all out. They call it Zero-Knowledge Compliance. The idea is to prove that you passed a Know your Customer check. Prove that a trade order is completely legitimate, not being broadcasted to the recording ledger. This is not an empty 'Trust me'.
It's an Actual proof that can be checked. But the content underneath the layer stays yours ( the person who made the trade).
If you want to look at the bigger picture. Just think for a second. A market maker cannot function if every bid is sitting there in public. Someone can React before this bid is even settled.
A company does not want a Treasury transfer showing up on the chain either.
A bank statement never works that way.
None of that is paranoia.
It is how finance already operates. Most public chains ignore this problem .
FULL TRANSPARENCY WAS A THING TO BE BUILT FIRST.
The General Data Protection Regulation angle stuck with me the most because of this.
Europe already decided PRIVACY is not OPTIONAL. It is the law.
The markets in Crypto-Assets Regulation builds on that for Asset specifically. A transparent chain is not an inconvenience for a European institution then. It is arguably not complaint with the rules they already follow, with the GDPR and markets in crypto-Assets regulation.
SELECTIVE DISCLOSURE is the mechanism, underneath all of this. Not everything is hidden. Not Everything is public. The market actor decides who sees what, who sees the trade order. A regulator can still audit when they need to pick a side.
$DUSK
Have you ever placed a trade. Then someone else quickly jumps in front of you? Have you ever thought it was bad luck?
Then I found the actual problem, reading through Dusk's official docs. My orders were fully transparent before they even settled. Visible to everyone. Wasn't a glitch. Someone was just watching them 🙁
@Dusk 's approach to this problem is what made me figure it all out. They call it Zero-Knowledge Compliance. The idea is to prove that you passed a Know your Customer check. Prove that a trade order is completely legitimate, not being broadcasted to the recording ledger. This is not an empty 'Trust me'.
It's an Actual proof that can be checked. But the content underneath the layer stays yours ( the person who made the trade).
If you want to look at the bigger picture. Just think for a second. A market maker cannot function if every bid is sitting there in public. Someone can React before this bid is even settled.
A company does not want a Treasury transfer showing up on the chain either.
A bank statement never works that way.
None of that is paranoia.
It is how finance already operates. Most public chains ignore this problem .
FULL TRANSPARENCY WAS A THING TO BE BUILT FIRST.
The General Data Protection Regulation angle stuck with me the most because of this.
Europe already decided PRIVACY is not OPTIONAL. It is the law.
The markets in Crypto-Assets Regulation builds on that for Asset specifically. A transparent chain is not an inconvenience for a European institution then. It is arguably not complaint with the rules they already follow, with the GDPR and markets in crypto-Assets regulation.
SELECTIVE DISCLOSURE is the mechanism, underneath all of this. Not everything is hidden. Not Everything is public. The market actor decides who sees what, who sees the trade order. A regulator can still audit when they need to pick a side.
Opened my first $DUSK futures position today, mostly to watch this mechanism from the inside rather than just describe it. Interesting to see funding/margin settle fast enough that it doesn't feel like the T+2 world from the post above — same underlying point, just experienced instead of explained this time. $DUSK #dusk
Luke_龙
·
--
#dusk $DUSK
I Kept seeing people ask the same question in different words: that is "okay, but how does any of this layer and mechanics stuff actually touch a regular person?"
Fair question — a settlement layer means nothing without something built on top of it. And it turns out @Dusk already has an answer for that layer, and the mechanics behind it are the interesting part.
How !My answer is simple.
A traditional bond or ETF trade doesn't settle in one step.
The broker confirms the order, a clearinghouse nets and matches it against every other trade that day, a custodian physically moves the asset between accounts, and a registrar updates who legally owns it — four separate organizations, each running their own system, each waiting on the one before it to finish before they can act. T+2 isn't a technology limit, it's the time it takes those four handoffs to complete in sequence.
Collapse ownership, payment, and custody into one ledger, and there's nothing left to hand off — the trade executing is the ownership update, in the same transaction
The specific piece doing this work is Dusk's transfer contract — the entry point every transaction runs through, whether it's a transparent Moonlight transfer or an obfuscated Phoenix one. It checks ownership, verifies the balance covers the transfer, and confirms nothing's being double-spent, all in the same step the trade executes, not as a follow-up reconciliation.
Finality isn't probabilistic either: the Succinct Attestation consensus confirms a block through a propose-validate-ratify vote and locks it in within seconds, So there's no waiting period where the trade could still be reversed the way a pending bank transfer can be.
That's the actual Replacement for the broker/clearinghouse/custodian/registrar chain, one contract doing the checking, one consensus round doing the finality.
It's also structured to operate under applicable EU regulatory frameworks, not as an offshore workaround — the same instinct behind Hedger: privacy and compliance aren't competing goals here.
I Kept seeing people ask the same question in different words: that is "okay, but how does any of this layer and mechanics stuff actually touch a regular person?"
Fair question — a settlement layer means nothing without something built on top of it. And it turns out @Dusk already has an answer for that layer, and the mechanics behind it are the interesting part.
How !My answer is simple.
A traditional bond or ETF trade doesn't settle in one step.
The broker confirms the order, a clearinghouse nets and matches it against every other trade that day, a custodian physically moves the asset between accounts, and a registrar updates who legally owns it — four separate organizations, each running their own system, each waiting on the one before it to finish before they can act. T+2 isn't a technology limit, it's the time it takes those four handoffs to complete in sequence.
Collapse ownership, payment, and custody into one ledger, and there's nothing left to hand off — the trade executing is the ownership update, in the same transaction
The specific piece doing this work is Dusk's transfer contract — the entry point every transaction runs through, whether it's a transparent Moonlight transfer or an obfuscated Phoenix one. It checks ownership, verifies the balance covers the transfer, and confirms nothing's being double-spent, all in the same step the trade executes, not as a follow-up reconciliation.
Finality isn't probabilistic either: the Succinct Attestation consensus confirms a block through a propose-validate-ratify vote and locks it in within seconds, So there's no waiting period where the trade could still be reversed the way a pending bank transfer can be.
That's the actual Replacement for the broker/clearinghouse/custodian/registrar chain, one contract doing the checking, one consensus round doing the finality.
It's also structured to operate under applicable EU regulatory frameworks, not as an offshore workaround — the same instinct behind Hedger: privacy and compliance aren't competing goals here.
Проверено
Холдинг $DUSK 10.7 USDT
#dusk $DUSK
I Kept seeing people ask the same question in different words: that is "okay, but how does any of this layer and mechanics stuff actually touch a regular person?"
Fair question — a settlement layer means nothing without something built on top of it. And it turns out @Dusk already has an answer for that layer, and the mechanics behind it are the interesting part.
How !My answer is simple.
A traditional bond or ETF trade doesn't settle in one step.
The broker confirms the order, a clearinghouse nets and matches it against every other trade that day, a custodian physically moves the asset between accounts, and a registrar updates who legally owns it — four separate organizations, each running their own system, each waiting on the one before it to finish before they can act. T+2 isn't a technology limit, it's the time it takes those four handoffs to complete in sequence.
Collapse ownership, payment, and custody into one ledger, and there's nothing left to hand off — the trade executing is the ownership update, in the same transaction
The specific piece doing this work is Dusk's transfer contract — the entry point every transaction runs through, whether it's a transparent Moonlight transfer or an obfuscated Phoenix one. It checks ownership, verifies the balance covers the transfer, and confirms nothing's being double-spent, all in the same step the trade executes, not as a follow-up reconciliation.
Finality isn't probabilistic either: the Succinct Attestation consensus confirms a block through a propose-validate-ratify vote and locks it in within seconds, So there's no waiting period where the trade could still be reversed the way a pending bank transfer can be.
That's the actual Replacement for the broker/clearinghouse/custodian/registrar chain, one contract doing the checking, one consensus round doing the finality.
It's also structured to operate under applicable EU regulatory frameworks, not as an offshore workaround — the same instinct behind Hedger: privacy and compliance aren't competing goals here.
I Kept seeing people ask the same question in different words: that is "okay, but how does any of this layer and mechanics stuff actually touch a regular person?"
Fair question — a settlement layer means nothing without something built on top of it. And it turns out @Dusk already has an answer for that layer, and the mechanics behind it are the interesting part.
How !My answer is simple.
A traditional bond or ETF trade doesn't settle in one step.
The broker confirms the order, a clearinghouse nets and matches it against every other trade that day, a custodian physically moves the asset between accounts, and a registrar updates who legally owns it — four separate organizations, each running their own system, each waiting on the one before it to finish before they can act. T+2 isn't a technology limit, it's the time it takes those four handoffs to complete in sequence.
Collapse ownership, payment, and custody into one ledger, and there's nothing left to hand off — the trade executing is the ownership update, in the same transaction
The specific piece doing this work is Dusk's transfer contract — the entry point every transaction runs through, whether it's a transparent Moonlight transfer or an obfuscated Phoenix one. It checks ownership, verifies the balance covers the transfer, and confirms nothing's being double-spent, all in the same step the trade executes, not as a follow-up reconciliation.
Finality isn't probabilistic either: the Succinct Attestation consensus confirms a block through a propose-validate-ratify vote and locks it in within seconds, So there's no waiting period where the trade could still be reversed the way a pending bank transfer can be.
That's the actual Replacement for the broker/clearinghouse/custodian/registrar chain, one contract doing the checking, one consensus round doing the finality.
It's also structured to operate under applicable EU regulatory frameworks, not as an offshore workaround — the same instinct behind Hedger: privacy and compliance aren't competing goals here.
Проверено
Холдинг $DUSK 9.9 USDT
#dusk $DUSK @Dusk
Kept seeing "RWA tokenization" thrown around like it's already solved. Dug into what @Dusk actually means by it and realized most "tokenization" is doing way less than it sounds like.
Here's the thing nobody mentions: when you tokenize a bond the normal way, you wrap it — the token trades on-chain, but the actual bond still lives in a legacy database, under legacy custody, settled the old way. You've digitized the label, not the asset. Trading might move fast, but clearing, custody, and settlement are still stuck in the system they always were.
Native issuance is a different claim entirely: the asset is born on-chain, with compliance, trading rules, and settlement Logic built into the protocol from day one — not bolted on after.
Instead of a bond and a separate token pointing at it, there's one record that carries issuance, ownership, transfers, servicing, reporting, and settlement all the way through.
The inference that actually got me: most people assume "on-chain" automatically means "faster," but the real bottleneck was never blockchain speed — it's disconnected records forcing reconciliation between six different systems that don't talk to each other.
Dusk's bet is that connecting the whole lifecycle matters more than any individual step being fast.
Genuinely curious — if the whole asset lifecycle moved on-chain like this, would that actually change how people trust financial products, or does trust in the end still come down to who's regulating it?
Kept seeing "RWA tokenization" thrown around like it's already solved. Dug into what @Dusk actually means by it and realized most "tokenization" is doing way less than it sounds like.
Here's the thing nobody mentions: when you tokenize a bond the normal way, you wrap it — the token trades on-chain, but the actual bond still lives in a legacy database, under legacy custody, settled the old way. You've digitized the label, not the asset. Trading might move fast, but clearing, custody, and settlement are still stuck in the system they always were.
Native issuance is a different claim entirely: the asset is born on-chain, with compliance, trading rules, and settlement Logic built into the protocol from day one — not bolted on after.
Instead of a bond and a separate token pointing at it, there's one record that carries issuance, ownership, transfers, servicing, reporting, and settlement all the way through.
The inference that actually got me: most people assume "on-chain" automatically means "faster," but the real bottleneck was never blockchain speed — it's disconnected records forcing reconciliation between six different systems that don't talk to each other.
Dusk's bet is that connecting the whole lifecycle matters more than any individual step being fast.
Genuinely curious — if the whole asset lifecycle moved on-chain like this, would that actually change how people trust financial products, or does trust in the end still come down to who's regulating it?
most people hear "1,000 DUSK minimum" and stop there — the part that actually matters is what happens after you stake. deterministic sortition recalculated every round, a maturity delay that closes off last-minute vote-swinging, penalties that make skipping or double-voting actually cost you. that's the difference between "technically decentralized" and a system built to stay honest without anyone having to trust a single party #dusk $DUSK
Luke_龙
·
--
Kept seeing "become a validator" tossed around like it's some closed club for whales 🐋.
Went and checked Dusk's actual numbers instead of assuming😎.
Minimum stake to run a provisioner on @Dusk is 1,000 DUSK🤫.
It's Not Zero, but not the six-figure buy-in some chains quietly require either.
Here's the cause and effect that matters more than the entry price though:
your chance of getting picked to propose or validate a block is proportional to your stake, calculated fresh every single time through something called deterministic sortition.
More stake, more frequent selection — but it's not winner-take-all like mining, where the biggest rig just wins every round.
The part I didn't expect: stakes aren't active immediately. There's a maturity period tied to Dusk's epoch system (2,160 blocks), so a stake only becomes eligible at the start of the next epoch after it matures.
That delay isn't a bug — it's what stops someone from staking right before a vote just to swing outcomes, then un-staking after.
Why this actually matters if you're not planning to validate anything: every provisioner who skips voting or double-votes gets penalized — soft slashing locks part of their stake, major faults burn it outright.🤷
That's not abstract governance trivia.
It's the reason the chain you're transacting on stays live and honest without you having to trust any single party to behave😊.
Now My time to Check your Opinions:
How do you think Dusk decides who gets picked to validate a block"
🎲 Random, no weighting
💰 Proportional to stake
🏆 First come, first served
🖥️ Based on hardware power
There could only be one Correct Option, just like there could be one winner in a 1v1 game.😎
#dusk $DUSK
Went and checked Dusk's actual numbers instead of assuming😎.
Minimum stake to run a provisioner on @Dusk is 1,000 DUSK🤫.
It's Not Zero, but not the six-figure buy-in some chains quietly require either.
Here's the cause and effect that matters more than the entry price though:
your chance of getting picked to propose or validate a block is proportional to your stake, calculated fresh every single time through something called deterministic sortition.
More stake, more frequent selection — but it's not winner-take-all like mining, where the biggest rig just wins every round.
The part I didn't expect: stakes aren't active immediately. There's a maturity period tied to Dusk's epoch system (2,160 blocks), so a stake only becomes eligible at the start of the next epoch after it matures.
That delay isn't a bug — it's what stops someone from staking right before a vote just to swing outcomes, then un-staking after.
Why this actually matters if you're not planning to validate anything: every provisioner who skips voting or double-votes gets penalized — soft slashing locks part of their stake, major faults burn it outright.🤷
That's not abstract governance trivia.
It's the reason the chain you're transacting on stays live and honest without you having to trust any single party to behave😊.
Now My time to Check your Opinions:
How do you think Dusk decides who gets picked to validate a block"
🎲 Random, no weighting
💰 Proportional to stake
🏆 First come, first served
🖥️ Based on hardware power
There could only be one Correct Option, just like there could be one winner in a 1v1 game.😎
#dusk $DUSK
Войдите, чтобы посмотреть больше материала