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?
|
|
||
| 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.
|
|
||
| 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.
There was a problem hiding this comment.
@IkerAlus your intuition was right, I've double checked everything, the bridge that is used by default is PoA Bridge (built by Defuse Labs) and the contract omft.near belongs to it
though bridging can be done via Omni Bridge as well (using their SDK), but that's not a default that's offered on NEAR Intents UI
I've updated the blog post so it no longer mentions Omni Bridge
…laiened in the blog post
render
Bot
temporarily deployed
to
add-near-intents-blogpost - docs.near.org PR #2963
IkerAlus
left a comment
IkerAlus
left a comment
There was a problem hiding this comment.
LGTM now with the update to PoA bridge.
I would keep an eye on the actual workflow since the idea is that indeed omnibridge will be eventually used.
3 participants
No description provided.