feat: add blog post about architecture of NEAR Intents#2963
feat: add blog post about architecture of NEAR Intents#2963
Conversation
|
hi @denbite has this blogpost been previously published elsewhere as a standalone article? or is it purely new content? |
|
@IkerAlus it's new blog post, it wasn't published anywhere else |
IkerAlus
left a comment
IkerAlus
left a comment
There was a problem hiding this comment.
Since it is the main point of the article, I recommend to double check the exact usage or role of Omnibridge with Near Intents in the workflow suggested here. I see couple of things that may be mistaken or not explained properly (see comments).
Also, will this article be linked somewhere from the official Near docs?
|
|
||
| Given the bast amount of chains and assets that have surged, it is now common for users to need to swap assets across chains (e.g. swap USDT on Ethereum for SOL on Solana). | ||
|
|
||
| Since **each blockchain is a separate and isolated system** - indeed, blockchains do not have any inherent way to communicate with each other - different off-chain services emerged to enable cross-chain swaps. Briefly, these services |
There was a problem hiding this comment.
Last sentence here seems to be missing
|
|
||
| The main point of trust here is in the **bridge itself**. You need to trust that the bridged assets will arrive in the target chain, and that the bridge is secure enough to prevent theft or loss of funds. | ||
|
|
||
| Furthermore, when using bridges you usually receive a wrapped version of the asset rather than the token itself, which means it might be difficult to swap the bridged asset for the native one if the bridge does not have enough liquidity on the target chain. |
There was a problem hiding this comment.
I would remove this sentence, it is not too clear to me what it is trying to say and also bridges should solve the general issue with proper lock / unlock or burn / mint mechanisms.
| 1. The Omni Bridge: a **trustless bridge** that securely moves assets from and to NEAR | ||
| 2. NEAR Intents, that **finds a counterparty** and **executes the swap** atomically on NEAR | ||
|
|
||
| For the user, the experience is simple and intuitive: |
There was a problem hiding this comment.
reading the points below, the reader may be wondering how omnibridge is a key component since it is not mentioned at all. I recommend you to rewrite these two paragraphs.
|
|
||
| ## Technical Foundations | ||
|
|
||
| The core technical foundation that makes all of this possible is the combination of **on-chain Multi-Party Computation**, the protocol's ability to handle true **asynchronous execution**, the **yield and resume** mechanism of smart contracts to handle long-lived flows without excessive costs, and **callback-based token standards**. |
There was a problem hiding this comment.
Mention chain signatures here so it is easy to link concepts for the reader
| ### Chain Signatures | ||
| [Chain Signatures](/chain-abstraction/chain-signatures) allows **smart contracts to sign transactions** for NEAR and **other chains** in a secure and deterministic way. It is based on multi-party computation (MPC), where a group of participants collectively generates a signature without any single party ever owning the full private key. | ||
|
|
||
| While MCP is a powerful primitive that exists on other chains, in NEAR it is naturally integrated into the on-chain execution thanks to the fact that smart contracts can yield and resume computation. |
| It is important to remark that, contracts can yield and resume computation **without blocking the blockchain** or **even themselves**! Indeed, thanks to the asynchronous nature of NEAR, contracts can have multiple flows in flight at the same time, each waiting for different signatures or events, and the chain can process them all in parallel without any bottlenecks. | ||
|
|
||
| ### Mature Token Standards | ||
| Once signing transactions for foreign chain becomes reliable and affordable, token flows themselves need to support complex swaps logic. |
There was a problem hiding this comment.
I am not sure I get what this sentence means
|
|
||
| From the user's point of view, the action is simple - they send their `USDT` to this `Ethereum` address. Once the transaction is included and finalized on `Ethereum`, it is automatically detected by external indexers and a cryptographic proof is generated that confirms the transfer really happened. | ||
|
|
||
| This proof is then processed on NEAR Protocol by the NEAR Intents smart contract, which then forwards it to the Omni Bridge smart contract `omft.near`. Once the Omni Bridge contract verifies the proof, it makes a cross-contract call to the child smart contract that represents a bridged token (for `USDT` the address is `eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near`) to mint the same amount that was deposited on Ethereum. |
There was a problem hiding this comment.
not sure of some of the information written here:
omft.nearis not Omni bridge smart contract.eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.nearis not the USDT address for bridged USDT over omnibirdge.- Not sure Omnibrdige is being used in the current passive deposit workflow.
2 participants
No description provided.