DEV Community: 0x.Mordegeer

STON.fi Omniston: Cross-Chain Liquidity Without Traditional Bridges

0x.Mordegeer — Wed, 16 Sep 2026 18:06:17 +0000

Deconstructing Omniston: The Architectural Blueprint of STON.fi’s Bridge-Less Cross-Chain Liquidity Protocol

The cross-chain landscape in Decentralized Finance (DeFi) has historically been plagued by catastrophic vulnerabilities. Wrapped asset bridges and centralized multisig custodians have accounted for over $2 billion in exploited value. As the ecosystem matures, the paradigm is shifting from custodial asset wrapping to native, trust-minimized atomic swaps.

At the forefront of this evolution is STON.fi and its underlying cross-chain aggregation protocol, Omniston.

This article presents a technical analysis of the Omniston protocol architecture, detailing how it achieves bridge-less cross-chain swaps, mitigates MEV and slippage, and leverages TON’s asynchronous actor-model architecture to create a unified cross-chain liquidity layer.

1. The Core Paradigm: Bridge-Less vs. Bridge-Based Swaps

To understand Omniston, one must first understand the fundamental security flaw of traditional cross-chain solutions:

Traditional Lock-and-Mint Bridges: Lock asset $A$ on Chain 1 and mint a synthetic/wrapped representation $wA$ on Chain 2. This introduces systemic collateral risk, multisig key compromise risk, and depegging exposure.
Omniston Native Atomic Swaps: Facilitate $A \to B$ exchanges where native tokens never leave their home chains, and no synthetic tokens are issued.

Omniston fundamentally operates as an Intent-based Liquidity Aggregation Network. Instead of routing transactions through fragile smart-contract bridges, it abstracts cross-chain execution into cryptographic commitments enforced natively on each participating blockchain.

2. Omniston Protocol Architecture: Component Breakdown

The Omniston architecture decouples trade intent, pricing/routing competition, and on-chain settlement.

 [ User Intent ] ---> [ Omniston Aggregator Layer ]
                            |
           +----------------+----------------+
           |                                 |
   [ Resolver 1 (RFQ) ]             [ Resolver 2 (RFQ) ]
           |                                 |
           +----------------+----------------+
                            | (Winning Quote)
                            v
        [ Cryptographic Settlement Engine (HTLC/PTLC) ]
                            |
           +----------------+----------------+
           |                                 |
     (Chain A: TON)                  (Chain B: EVM/TRON)
  Native Token Lock               Native Token Settlement

A. The Intent & RFQ (Request-For-Quote) Layer

Instead of executing trades against static, path-dependent AMM pools across chains, Omniston uses an Intent-Driven Architecture:

User Request: The user specifies input asset, output asset, maximum slippage, and target execution parameters.
RFQ Auction: Off-chain actors called Resolvers (Market Makers, Institutional Searchers, or Automated Arbitrageurs) compete to fulfill the trade.
Best Price Guarantee: Resolvers combine off-chain liquidity, internal inventory, and on-chain AMMs (such as STON.fi on TON or Uniswap on Ethereum) to quote the optimal route.

B. The Settlement Engine (Zero-Bridge Security)

Settlement relies on Hashed Timelock Contracts (HTLCs) and advanced cryptographic primitives like Point Timelock Contracts (PTLCs) using Schnorr/Ed25519 signature schemes where applicable.

Hashlock Condition ($H = \text{Hash}(S)$): Funds locked by both parties are redeemable only upon revealing the cryptographic secret $S$ (preimage).
Timelock Condition ($T_1, T_2$): If $S$ is not revealed within window $T$, funds automatically revert to their original owners, preventing capital lockup attacks.

3. End-to-End Execution Lifecycle of a Cross-Chain Swap

Let's trace a practical scenario: Swapping native $TON on the TON Blockchain for native $USDT on an EVM destination chain without a central intermediary.

+--------+            +----------+          +----------+            +--------+
| User   |            | Omniston |          | Resolver |            | Chains |
+---+----+            +----+-----+          +----+-----+            +---+----+
    |                      |                     |                      |
    | 1. Submit Intent     |                     |                      |
    +--------------------->|                     |                      |
    |                      | 2. Broadcast RFQ    |                      |
    |                      +-------------------->|                      |
    |                      | 3. Submit Quote     |                      |
    |                      |<--------------------+                      |
    | 4. Sign Trade Commitment                   |                      |
    +------------------------------------------------------------------>| (Chain A Lock)
    |                      |                     | 5. Verify & Lock     |
    |                      |                     +--------------------->| (Chain B Lock)
    | 6. Reveal Secret (S) to Claim Funds        |                      |
    +------------------------------------------------------------------>| (Chain B Claim)
    |                      |                     | 7. Use (S) to Claim  |
    |                      |                     +--------------------->| (Chain A Claim)

Step 1: Off-Chain Intent Generation

The user signs an execution order specifying the parameters ($1000 \text{ TON} \to \text{USDT}$). A random secret value $S$ is generated locally on the user's client, and its hash $H = \text{Hash}(S)$ is appended to the order payload.

Step 2: Resolver Competition & Selection

Omniston's relay network broadcasts $H$ and the swap parameters to active Resolvers. The winning Resolver guarantees a fixed rate $R$ for execution.

Step 3: Source Chain Escrow (TON)

The user deposits $1000 \text{ TON}$ into the TON Settlement Smart Contract locked under condition $H$ with timelock $T_1$.

Architectural Note on TON: Due to TON's asynchronous message delivery, the smart contract utilizes an actor-model lifecycle, transitioning states upon confirmation of a valid inbound message payload.

Step 4: Destination Chain Escrow (Target Chain)

The winning Resolver sees the user’s funds locked on TON. The Resolver then locks the equivalent amount of native $USDT$ into the target chain’s HTLC contract using the same hash $H$ and a shorter timelock $T_2$ ($T_2 < T_1$ to protect the Resolver from option risk).

Step 5: Atomic Settlement via Secret Revelation

The user claims the $USDT$ on the target chain by revealing secret $S$ on-chain.
The secret $S$ is now publicly readable in the target chain’s transaction history.
The Resolver reads $S$ from the target chain mempool/ledger and uses it to unlock and claim the $1000 \text{ TON}$ locked on the TON blockchain.

If either party defaults before $S$ is revealed, $T_2$ expires, allowing the Resolver to withdraw their $USDT$, followed by $T_1$ expiring, returning the $TON$ to the user. Atomicity is preserved; assets are either swapped completely or returned.

4. Architectural Integration with TON’s Unique Async Model

Building Omniston on TON presents unique structural challenges compared to synchronous environments like Ethereum:

Asynchronous Message Passing

TON does not allow synchronous multi-contract calls within a single transaction block. Omniston handles this via Actor-driven State Machines:

Optimistic Local Execution: Transaction steps are broken down into self-contained message passes between the User Wallet, Aggregator Router, and Vault Contracts.
Non-blocking State Transitions: Failed states emit exit messages that trigger asynchronous rollbacks, ensuring user funds are never trapped mid-flight due to shard reorgs or message drops.

[ User Contract ] 
      │
      ▼ (Inbound Msg: Lock Funds)
[ STON.fi Vault Contract ] ──► (Emits Event: Lock Confirmed)
      │
      ▼ (Async Off-chain Event Capture)
[ Omniston Relayer Network ]

5. Security Architecture & Threat Vectors

Omniston mitigates common attack vectors associated with cross-chain execution:

Threat Vector	Mitigation in Omniston Protocol
MEV / Front-Running	Resolvers commit to fixed quotes via signed off-chain RFQs. Price execution is isolated from public mempools.
Bridge Exploits / Hacks	No central bridge pool exists. Capital is stored transiently in individual user HTLC instances or local liquidity pools.
Resolver Default	Timelocks ($T_1, T_2$) guarantee that if a Resolver fails to complete the target-chain deposit, user funds unlock automatically.
Griefing Attacks	Resolvers require cryptographic commitments from the user before locking target liquidity, eliminating zero-cost spamming.

6. The Broader Vision: The "One Swap. Across Chains" Ecosystem

By unifying DEX liquidity on TON with institutional liquidity providers and external EVM/non-EVM ecosystems, Omniston transforms STON.fi from an isolated AMM into a universal cross-chain liquidity protocol.

Unified User Experience: The complexity of managing gas tokens on secondary chains, secret generation, and monitoring block confirmations is abstracted away into single-click interactions.
Deep Capital Efficiency: Resolvers leverage centralized and decentralized liquidity sources globally, giving end-users institutional-grade rates that single AMM pools cannot match.

Technical Conclusion

Omniston represents a maturation of cross-chain DeFi infrastructure. By replacing brittle bridge smart contracts with cryptographic atomicity, intent-driven RFQ execution, and off-chain routing competition, STON.fi establishes a safe blueprint for native asset inter-blockchain communication (IBC).

For the TON ecosystem, this unlocks seamless capital inflows from traditional and EVM networks—solidifying its position as a primary hub for scalable, cross-chain Web3 applications.

ton #defi #web3

BrowserSkill: Connecting Autonomous AI Agents to Live Browser Sessions

0x.Mordegeer — Wed, 16 Sep 2026 17:59:57 +0000

---
title: "Tencent Open-Sources BrowserSkill: Bridging AI Agents to Live Browser Sessions"
published: true
tags: ai, web3, automation, python
---

# Tencent Open-Sources BrowserSkill: Bridging AI Agents to Live Browser Sessions

As AI agents evolve from basic conversational interfaces into autonomous task executors, real-world web interaction remains one of their biggest bottlenecks. Standard frameworks like Playwright or Puppeteer typically spawn fresh, isolated Chromium instances. While clean, these sandboxes lack your active sessions, authenticated cookies, and human browser fingerprints—frequently triggering anti-bot systems like Cloudflare, Akamai, or DataDome.

Tencent recently open-sourced **BrowserSkill**, an infrastructure layer designed to solve this exact problem. Instead of spinning up isolated environments, BrowserSkill allows agents powered by Claude, OpenAI Codex, or local LLMs to attach directly to your active browser context without triggering anti-fraud mechanisms.

---

## The Sandbox Bottleneck in Agentic Workflows

Traditional browser automation relies on programmatic driver instances. For enterprise and Web3 workflows, this architecture breaks down due to three major limitations:

1. **Authentication Friction**: Fresh instances require re-authenticating past Multi-Factor Authentication (MFA), OAuth flows, or hardware security keys on every run.
2. **Anti-Fraud Flagging**: Automated drivers expose distinct automation flags (`navigator.webdriver`, synthetic canvas rendering, unnatural TLS client hellos) that modern anti-bot services detect instantly.
3. **Context Isolation**: Web3 dApps, internal SaaS tools, and customized dashboards rely heavily on extension states (e.g., MetaMask, Phantom) and localized IndexedDB data that don't exist in clean driver profiles.

---

## How BrowserSkill Works Under the Hood

BrowserSkill shifts the automation paradigm from *browser instantiation* to *session attachment*. It connects your AI agent directly to an already running, user-authenticated browser process via low-level debugging interfaces.


### Key Architectural Features:

* **CDP Multiplexing**: Hooks into Chrome DevTools Protocol (CDP) on an active debugging port (e.g., `--remote-debugging-port=9222`), preserving native DOM state and running extension processes.
* **Fingerprint Parity**: Because actions execute inside your primary browser profile, request signatures retain genuine TLS signatures, IP consistency, mouse hardware trajectories, and established session tokens.
* **Context Preservation**: Agents inherit active local storage, session storage, and cookie jars directly, bypassing login screens entirely.

---

## Python Integration Example

Integrating BrowserSkill into an existing Python agent framework requires minimal boilerplate. Here is a simplified conceptual setup attaching an agent to a live session:

python
from browserskill import BrowserSkillDriver
from langchain.agents import initialize_agent

Connect to the local running Chrome instance

driver = BrowserSkillDriver(
cdp_endpoint="http://localhost:9222",
stealth_mode=True
)

Fetch active page context without triggering re-login

context = driver.get_active_session_context()

print(f"Connected to domain: {context.current_domain}")
print(f"Authenticated session state: {context.has_active_session}")

Agent performs actions using existing cookies and storage

driver.execute_agent_action(
action="click",
selector="#submit-tx-btn",
human_delay=True
)


---

## High-Value Use Cases

1. **Web3 Automation**: Executing dApp interactions without exposing raw private keys to LLMs. The agent navigates the web interface while the user approves transactions through native browser extension wallets.
2. **Authenticated SaaS Pipelines**: Automating analytics extractions, internal CRM updates, or admin panel actions behind complex SSO and hardware-bound auth layers.
3. **Anti-Fraud Evasion**: Executing scraping and browser tasks on high-security platforms without relying on costly IP rotation networks or CAPTCHA-solving services.

---

## Security Considerations & Conclusion

Connecting an autonomous LLM to a live session with active bank, email, or Web3 permissions introduces obvious security risks. Prompt injection attacks could potentially hijack the agent to execute unauthorized actions within an authenticated session. Implement strict execution boundaries, manual approval gates for sensitive DOM events, and rate-limiting when deploying BrowserSkill production pipelines.

Tencent’s BrowserSkill is a significant step toward context-aware, local-first agentic infrastructure. By giving models safe access to native human browser states, it removes the cold-start authentication penalty and unlocks true end-to-end automation.

Omniston protocol: будущее децентрализованной ликвидности без мостов

0x.Mordegeer — Wed, 16 Sep 2026 17:47:00 +0000

DeFi #TON #STONfi #Omniston

Omniston Protocol: будущее децентрализованной ликвидности без мостов

Кроссчейн-взаимодействие остаётся самым уязвимым и сложным звеном современного Web3. За последние годы индустрия потеряла миллиарды долларов из-за взломов кастодиальных мостов и уязвимостей в смарт-контрактах «обёрнутых» токенов (wrapped tokens). Фрагментация ликвидности между изолированными блокчейнами создает высокую проскальзываемость (slippage) и ухудшает пользовательский опыт.

Команда STON.fi предложила архитектурный ответ на этот вызов — Omniston, децентрализованный протокол агрегации ликвидности, который меняет парадигму кроссчейн-обменов и полностью отказывается от традиционных мостов.

Проблема традиционных мостов и фрагментации

Классические кроссчейн-мосты работают по схеме Lock-and-Mint (блокировка актива в одной сети и выпуск его synthetic-копии в другой). Это создаёт две фундаментальные проблемы:

Риски безопасности: Централизованные смарт-контракты мостов превращаются в огромные «хранилища-приманки» (honeypots) для хакеров.
Низкая капитал-эффективность: Ликвидность оказывается заблокированной внутри отдельных экосистем, вынуждая пользователей совершать цепочки сложных и дорогих транзакций.

Экосистема TON (The Open Network), обладая уникальной асинхронной архитектурой и массовым охватом через Telegram, требует масштабируемого решения, способного связывать внутреннюю ликвидность с внешним криптомиром без потери безопасности.

Архитектура Omniston: Модель RFQ и Атомные Свопы

Omniston отказывается от идеологии «обёрнутых» токенов в пользу агрегации ликвидности на базе институциональной модели RFQ (Request-for-Quote) и криптографических атомных свопов (Atomic Swaps).

Логика работы протокола строится на взаимодействии трех ключевых компонентов:

Пользователь (Trader): Инициирует запрос на обмен (например, TON на BTC или USDT в другой сети).
Резолверы (Resolvers / Solvers): Профессиональные участники рынка (мейкеры), которые соревнуются за право исполнить ордер пользователя, предлагая лучшую цену.
Omniston Protocol: Децентрализованный слой маршрутизации и валидации, который выбирает оптимальное предложение и контролирует исполнение сделки.

[Пользователь] ---> Запрос (RFQ) ---> [Omniston Protocol]
                                            |
                                  Конкурс Резолверов
                                            |
[Атомный своп] <--- Лучшая цена <--- [Победивший Резолвер]

Как достигается отсутствие мостов?

Вместо перевода токенов через мост, Резолвер выплачивает пользователю нативный актив в целевой сети из собственных резервов. Обмен происходит атомно: транзакция либо исполняется одновременно в обеих сетях, либо полностью отменяется, а средства возвращаются владельцам.

Почему TON и STON.fi — идеальная среда для Omniston

Экосистема TON обладает высочайшей пропускной способностью, однако асинхронная природа блокчейна усложняет традиционный запуск AMM-маршрутизаторов. STON.fi интегрирует Omniston для решения ключевых задач:

Объединение ликвидности внутри TON: Omniston агрегирует глубину стаканов всех DEX, лимитных ордеров и частных пулов ликвидности в сети TON, исключая необходимость переходить между разными платформами.
Прямой мост к Telegram Web3: Миллионы пользователей Telegram Wallet получат доступ к институциональной ликвидности с лучшим исполнением цен прямо в интерфейсе мессенджера.
Минимизация MEV-атак: Модель RFQ защищает обычных пользователей от Sandwich-атак и переднебегущих ботов (front-running), так как цена фиксируется Резолвером до момента отправки транзакции.

Безопасность: Нулевой риск взлома моста

С точки зрения риск-менеджмента, Omniston кардинально превосходит классические решения:

Отсутствие единой точки отказа: В протоколе нет TVL, заблокированного в смарт-контракте моста. Хакеру просто нечего взламывать — средства находятся либо у пользователя, либо у Резолвера.
Защита от несостоятельности маркет-мейкера: Если Резолвер не исполнит свою часть сделки вовремя, криптографический таймлок (HTLC или его аналоги в TON) автоматически разблокирует средства пользователя.
Безопасность нативного уровня: Пользователи получают исключительно нативные токены (Native BTC, Native ETH, Native TON), избегая риска обесценивания синтетических wrapped-активов при взломе эмитента.

Заключение

Omniston от STON.fi — это не просто очередной агрегатор DEX. Это фундаментальный сдвиг в сторону Intent-centric DeFi (интент-ориентированных финансов), где пользователь заявляет желаемый результат, а децентрализованный рынок Резолверов обеспечивает его исполнение по наилучшей цене.

Убирая риски мостов и объединяя децентрализованную ликвидность TON с внешними сетями, Omniston закладывает основу для следующего этапа массового принятия Web3-финансов.