Crypto _Mars

Было время, когда я по-настоящему верил, что если мы сможем просто достаточно чётко и достаточно быстро видеть проблемы, то в итоге научимся справляться с ними. Помню, как смотрел на дашборды во время девальваций привязки и ликвидаций, обновлял их, словно они могли каким-то образом изменить то, что уже происходило. Данные были там. Предупреждения мигали. И всё равно деньги двигались дальше.
Этот опыт навсегда остался со мной. Со временем я начал замечать закономерность, которая казалась больше, чем любая отдельная неудача. В криптовалюте мы стали невероятно искусны в создании систем, которые могут показывать нам, когда что-то идёт не так. Но мы так и не построили системы, которые могли бы не дать этому случиться в первую очередь. Большая часть того, что мы называем управлением рисками, на самом деле является наблюдением за рисками — мы смотрим, оповещаем, обсуждаем, а потом пытаемся разобраться и навести порядок уже после того, как всё произошло.

Сколько себя помню, комплаенс воспринимали как злодея в криптоиндустрии.
Именно форма KYC вас и прерывает. Вывод средств, который внезапно ставят на паузу. Дополнительный шаг проверки, из‑за которого всё кажется медленнее, чем должно. Где‑то по пути мы начали относиться к комплаенсу как к противоположности хорошего пользовательского опыта. Быстро, без разрешений, без трений — вот была цель. Комплаенс был просто ценой, которую институции хотели, чтобы платили все остальные.
Но я не думаю, что настоящая проблема — в этом.

Can I be honest for a second? When most projects say they have "privacy," I've learned to be a little suspicious. Not because the intent is bad, but because that word gets used to paper over a problem most teams haven't actually solved.
Here's the thing nobody wants to admit out loud: if your data is encrypted, and you need to check it against some rule a spending limit, a sanctions list, whatever somebody has to decrypt it first. There's no way around that. You simply cannot run a check on data you can't read.
So what happens in practice? Most "private" systems just quietly hand this job to one server. That server decrypts your data, checks the rule, sends back an answer. Which means your privacy now rests entirely on trusting one operator to not peek, not leak, not get hacked. That's not privacy. That's just you handing your risk to a guy in a hoodie and hoping for the best.
So How Does Newton Actually Handle This?
I went and checked Newton Protocol's actual documentation before writing this, because I didn't want to just repeat marketing copy. And to their credit, the architecture holds up.
Instead of one server holding the decryption key, Newton spreads it across multiple operators. Decryption only happens if a threshold number of them cooperate and here's the part I actually like not even the gateway itself ever holds the complete private key. So if one operator gets compromised, there's no full key sitting there for an attacker to grab.
There's a smaller detail that's easy to miss but honestly says a lot about how carefully this was built: an operator's threshold key share is cryptographically unrelated to their other signing keys. So hacking someone's regular signing key doesn't magically hand you access to the encrypted vault too. That's the kind of thing you only build if you've actually thought through how these systems fail in the real world.
Privacy and Authorization Aren't Separate Problems Here
This is the part I found genuinely interesting. Newton doesn't treat "keep it private" and "who's allowed to see it" as two different features bolted together. They combine HPKE encryption with dual-signature authorization into one primitive they call the Newton Privacy Envelope.
In plain English: both the user and the app have to sign off before any operator even gets a shot at looking at the encrypted data. No single party not even Newton itself gets to make that call alone. And the only thing that ever becomes visible is a simple yes or no. The actual data underneath stays encrypted the entire time.
That's the real innovation, if you ask me. It's not just "your data is hidden." It's "your data stays hidden, and the system can still make a trustworthy decision about it anyway."
One Thing I Respect: They're Not Overselling It
Here's something that actually built my trust in this project. Their docs openly admit that right now, they're using MPC for policy checks instead of full FHE and they explain exactly why. FHE is still somewhere between 1,000 and a million times slower than regular computation, depending on complexity. Production-ready FHE is still years away.
So instead of pretending they've solved a problem nobody's actually solved yet, they built the system so that when FHE does mature, they can swap it in without breaking anything — same encrypted data, same policies, same signed results, just faster under the hood eventually.
Honestly? That's rare. Most projects would rather oversell the tech than admit "we're using the practical solution for now."
Why Any of This Actually Matters
Take away all the jargon and here's what you're left with: nobody can see your full position on their own, nobody can approve or reject your transaction unilaterally, and yet the whole thing still produces a result you can actually trust and verify.
That's not a feature. That's a trust architecture. And it's exactly the kind of unglamorous engineering that decides whether a fund manager actually feels safe deploying capital on-chain or just keeps routing everything through the same old centralized broker because it's familiar.
The Question I Keep Coming Back To
As more serious money starts looking at DeFi, I think multi-party systems like this stop being a nice-to-have and start becoming the bare minimum. Single-signer setups have a rough history, they're usually the first thing that gets exploited.
So maybe the question isn't "does this have privacy." Maybe it's "do I actually trust what's happening behind the scenes."
That's a harder question to market with a flashy landing page. But it's the one that actually matters.
@NewtonProtocol #Newt $NEWT

Не поймите меня неправильно, мне нравятся умные ИИ-агенты, но мне они нравятся недостаточно. Не поймите меня неправильно, мне нравятся умные ИИ-агенты, но мне они нравятся недостаточно.
На прошлой неделе я видел арбитражного агента, который полностью прогнал свой пул залогов менее чем за 10 секунд из‑за убеждения в том, что данные коррупционного оракла цен были поданы неверно. Но по прошествии десяти секунд — да, после десяти секунд — месяцы сложных процентов оказываются стерты. Это было не потому, что искусственный интеллект был недостаточно умным. Модель представляла собой крайне сложную нейросеть, которая могла обрабатывать тысячи точек данных в секунду. Нет, потому что у агента не было контроля над ключами к кошельку и не было никаких сдерживающих факторов, чтобы не ошибиться. У этого парня был чрезвычайно быстрый мозг, но его клетка была из бумаги. Наша община годами интересовалась ботами и пыталась сделать их умнее и более независимыми. Однако я считаю, что по мере того, как мы начинаем 2026 год, это для нас опасное отвлечение. Несдерживаемый ИИ‑агент с приватным ключом — это не прорыв в мире on-chain финансов. Это бомба замедленного действия в финансовом кармане любого, кто может отправить промпт, который ее запускает, или хитроумного бота для опережающей торговли.

На прошлой неделе я видел разработчика, который буквально промок насквозь от пота во время живого обновления мейннета, и это было не из‑за активного эксплойта. Он просто панически боялся нулевого слота. Это заставило меня осознать, насколько хрупкими становятся наши неизменяемые системы в тот момент, когда мы пытаемся их менять.
DeFi полон протоколов, которые держат миллионы долларов и не могут просто остановиться, стереть всё начисто и начать заново. Им нужно улучшаться, продолжая работать, поэтому протокол Newton привлёк так много внимания. Он предлагает способ интегрировать предварительную авторизацию транзакций непосредственно в существующий контракт через прокси‑обновление. На первый взгляд это мечта разработчика. Вы наследуете NewtonPolicyClient, подключаете старый контракт к механизму политик и внезапно получаете риск‑контроли институционального уровня. Но если присмотреться внимательнее, становится ясно, что самые опасные ловушки кроются не в самой бизнес‑логике. Они прячутся в безмолвных слотах памяти Ethereum Virtual Machine.

Вчера я смотрел, как в обозревателе блоков разворачивается сценарий, где смарт-контракт выводит средства, и у меня возник простой вопрос: что происходит, когда транзакция валидна, но изначально намерение не должно было быть одобрено?
Эта напряжённость легко упустить в криптовалюте. Блокчейны очень хорошо справляются с расчётом (settlement). Они гораздо хуже справляются с авторизацией. В традиционных платежах авторизация происходит до того, как деньги сдвигаются с места. В DeFi подписанные транзакции часто сразу идут в исполнение, то есть система может сделать ровно то, что было запрошено, даже когда то, что было запрошено, было опасным.

Протокол Newton интересен тем, что заставляет задать вопрос, который многие DeFi-проекты пытаются обойти: что происходит, когда «бесконтрактное» выполнение все равно зависит от доверенных входных данных?
Согласно собственным материалам Ньютона, его mainnet-бета уже работает на Base и Ethereum, а оценка политики происходит до расчетов через операторов EigenLayer, политики на основе Rego, определения политик, хранящиеся в IPFS, и BLS-аттестацию. Протокол также поддерживает наборы данных оракулами, такими как Chainalysis, vaults.fyi, RedStone, Credora и Webacy. Технически это серьезная часть инфраструктуры. Но философски это еще и сдвиг: часть доверия переходит с чистого onchain-кода на качество, актуальность и управляемость (governance) внецепочечных источников данных.