I went looking for how Citadel actually handles a revoked credential. Turns out the answer isn't "the chain checks it." Dusk Network's Citadel protocol $DUSK #dusk lets a user prove a session is cryptographically valid — that a real License Provider signed a real license — but per the docs, that proof does not decide service policy. That call sits with the Service Provider. Per @Duskfoundation's own documentation, the SP decides which License Providers it trusts, which attributes it accepts, whether a session is expired or revoked, and whether the session cookie can be reused. None of that is written into the on-chain verification itself. What changed for me was realizing "privacy-preserving KYC" here doesn't mean the chain enforces compliance. Personal attributes are never written to the blockchain — that part's explicit in the docs. But expiry, revocation, and trust in the issuer are policy decisions each Service Provider makes independently, off-chain, with nothing on-chain forcing consistency between them. @Dusk
Подождите — то самое «защищающее» ваш торговый DuskEVM от ботов прямо сейчас — это вообще не какая-то модная технология. Все говорят о Hedger, privacy engine DuskEVM ($DUSK #dusk @DuskFoundation) — гомоморфное шифрование плюс ZK-доказательства, зашифрованные балансы, настоящая криптография. Но именно это сегодня не мешает фронтраннингу. Я проверил документацию. Сейчас DuskEVM работает только с секвенсором. Публичного мемпула нет. Один секвенсор — и нечего ботам «подсматривать», чтобы забежать вперёд. Это и есть реальный механизм. То есть здесь наложены друг на друга две разные истории про «приватность», и легко отнести заслуги не к той. Hedger — это настоящая криптографическая приватность, аудитопригодность заложена в дизайн. Защита от фронтраннинга — это другое явление, побочный эффект от того, что есть один секвенсор и ничего не выставлено наружу. Вот что я пока не нашёл: в документах или на дорожной карте есть ли указание, останется ли секвенсор DuskEVM одиночным или будет со временем открываться. Если когда-нибудь он станет многопартийным или публичным, этой конкретной защите нужно будет что-то вместо неё. Нигде это не подтверждено — по крайней мере, мне не попадалось. Это скорее вопрос, который поднимает текущая схема. Любопытно, отслеживал ли кто-то реальную дорожную карту секвенсора DuskEVM. Честно, не знаю ответа. @Dusk
Spent the afternoon poking around Dusk's repos instead of just reading the pitch deck. #Dusk $DUSK @DuskFoundation — "privacy on a public chain" is the whole TradFi hook, so I wanted to see what's actually moving, not what's being said. Here's the thing that stuck: duskevm-genesis, the repo holding the genesis block and rollup config, had commits land Aug 8 and Aug 10, 2026. Not RWA settlement code. Not a securities contract. Genesis and rollup plumbing — the boring, load-bearing stuff nobody screenshots. Meanwhile DUSK's most active pair, DUSK/USDT on Binance, was doing about $117k in 24h volume when I checked, against roughly $3.07M total across 51 markets (CoinGecko). For a project whose entire thesis is "institutions will finally transact on a public chain," that's a thin signal. Made me reconsider my own framing going in — I assumed compliant privacy meant invisible institutional flow humming in the background. What I found instead was infra still being wired, quietly, while the market cap sits under $50M. So which comes first here — the institutions Dusk keeps promising, or the plumbing finally catching up to the pitch? @Dusk
Чтение ограничений схемы Phoenix остановило меня. На Dusk $DUSK #dusk @Duskfoundation Контракт Transfer никогда не смотрит на реальные значения нот и на то, какой именно Merkle-лист используется. Он лишь проверяет PLONK-доказательство, что приватные входные данные удовлетворяют пяти условиям: хэш ноты открывается против недавнего Merkle-корня набора нот, доказчик знает секретный ключ ноты, нуллификатор равен Poseidon(npk′ ‖ position), выходные коммитменты корректно открываются, и сумма входных значений равна сумме выходов плюс fee, плюс любые депозиты. Сами нуллификаторы публикуются, чтобы сеть могла отклонять повторное использование. Поскольку каждый нуллификатор выводится из скрытого ключа ноты и позиции, ни один наблюдатель не может сопоставить нуллификатор обратно с конкретным листом. Проверка корректности полностью живёт внутри удовлетворения схемы; содержимое никогда не попадает в реестр. Для меня изменилось понимание того, что защита от двойных трат и целостность баланса обе встроены в доказательство, а не в какие-либо видимые изменения состояния. Следующая проверка: остаются ли опубликованные нуллификаторы каждого принятого транзакционного Phoenix уникальными в on-chain наборе нуллификаторов после финализации. @Dusk