near · matiasbenary · Jun 19, 2026
diff --git a/assets/blog/2024-review/2024-blog-2.jpg b/assets/blog/2024-review/2024-blog-2.jpg
diff --git a/assets/blog/2024-review/2024-blog-3.jpg b/assets/blog/2024-review/2024-blog-3.jpg
diff --git a/assets/blog/2024-review/2024-blog-4.jpg b/assets/blog/2024-review/2024-blog-4.jpg
diff --git a/assets/blog/2024-review/2024-blog-5.jpg b/assets/blog/2024-review/2024-blog-5.jpg
diff --git a/assets/blog/2024-review/2024-blog-6.jpg b/assets/blog/2024-review/2024-blog-6.jpg
diff --git a/assets/blog/2024-review/2024-blog.jpg b/assets/blog/2024-review/2024-blog.jpg
diff --git a/assets/blog/contract-wait-loop.png b/assets/blog/contract-wait-loop.png
diff --git a/assets/blog/contract-wait-yield.png b/assets/blog/contract-wait-yield.png
diff --git a/assets/blog/legendary.jpg b/assets/blog/legendary.jpg
diff --git a/assets/blog/native-cross-chain.png b/assets/blog/native-cross-chain.png
diff --git a/assets/blog/web3wallets/cover.png b/assets/blog/web3wallets/cover.png
diff --git a/assets/blog/web3wallets/diagram.png b/assets/blog/web3wallets/diagram.png
diff --git a/assets/blog/web3wallets/function-call.png b/assets/blog/web3wallets/function-call.png
diff --git a/assets/blog/web3wallets/login.png b/assets/blog/web3wallets/login.png
diff --git a/assets/blog/windows-features-wsl-enabled.jpg b/assets/blog/windows-features-wsl-enabled.jpg
diff --git a/assets/docs/welcome-pages/contracts-landing.png b/assets/docs/welcome-pages/contracts-landing.png
diff --git a/blog/2024-04-23-we-have-a-blog.mdx b/blog/2024-04-23-we-have-a-blog.mdx
@@ -0,0 +1,41 @@
+---
+title: "We have a blog now!"
+description: "Check check check. Is this thing on? Hello, world!"
+date: 2024-04-23
+author: "Guille"
+tags: [updates]
+---
+
+{/* BYLINE:start */}
+_**Guille** · April 23, 2024_
+{/* BYLINE:end */}
+
+*Check check check. Is this thing on? Hello, world!*
+
+<p><img src="/assets/docs/welcome-pages/1.near-protocol.png" /></p>
+
+## Hello there!
+Welcome to the new NEAR documentation blog! We're excited to inaugurate this new space where we can share news and updates. We know what you are thinking — why a blog? Well, it allows us to interact with you in a different way!
+
+When writing documentation, it is important for us to keep the content focused and concise. This way, when you read it, you have nothing to distract you, and you can focus on learning a new concept.
+
+The problem with this is that many times, we want to share ideas, thoughts, or insights into why some things are the way they are. However, this would imply going off on a tangent and explaining why some decisions were made, which will probably add noise to the document. Most of the time, users just want a link to an example or working code. Also, people don't like to read long texts.
+
+Besides that, sometimes we just want to share what we did during the week. For example, did you notice that we fixed the nightmare that was the URL structure, or that we added new landing pages for all concepts? We want to share these things with you, but they don't really belong in the Docs.
+
+<Tip>
+You would not believe the number of times we said during a review _"let's remove that, we are writing technical documentation, not a blog post"_ ... well, now we can make the blog post!
+</Tip>
+## What to expect
+
+We will be using this space to share updates about our docs, as well as **complement them** with additional information that we think you'll find interesting.
+
+Our aim is to keep the blog updated at least once a week, but given the limited amount of time we have, we will see how that goes.
+
+Moreover, we want to remind you that our Docs are an open source and **collaborative project**. If you feel like you have something to share, or want to contribute to the blog, feel free to reach out. And by reaching out, we mean [opening a PR](https://github.com/near/docs/pulls)!
+
+## A new era for NEAR docs
+
+We are super excited to start this new section and hope it helps us to connect with all of you in a better way. We are looking forward to hearing your thoughts and feedback, and hope you enjoy the content we'll be sharing.
+
+See you in the next post! 🚀
diff --git a/blog/2024-04-24-reorganizing-docs.mdx b/blog/2024-04-24-reorganizing-docs.mdx
@@ -0,0 +1,57 @@
+---
+title: "Reorganizing our docs"
+description: "We released a mayor reorganization of our repository, so we can improve docs for everyone... including us"
+date: 2024-04-24
+author: "Guille"
+tags: [docusaurus, updates]
+---
+
+{/* BYLINE:start */}
+_**Guille** · April 24, 2024_
+{/* BYLINE:end */}
+
+*We released a mayor reorganization of our repository, so we can improve docs for everyone... including us*
+
+<p><img src="https://img.freepik.com/free-photo/ancient-books-adorn-library-carefully-arranged-with-classics-rare-gems_157027-2332.jpg" /></p>
+
+## Organic growth
+Our documentation is the result of multiple people collaborating across the span of four very active years, and it has seen a lot of changes: [2942 commits and counting](https://github.com/near/docs/commits/master/).
+
+In the beginning, our docs only needed to explain how to create [smart contracts](/smart-contracts/what-is), and how to [interact with them through a frontend](/web3-apps/quickstart). Fast forward to today, and we have more than 200 pages of documentation, covering topics such as [chain abstraction](/chain-abstraction/what-is), [data infrastructure](/data-infrastructure/what-is), and [primitives such as NFT, FT](/primitives/what-is).
+
+The best thing is that new features are released every single month. However, all progress comes at a cost, and as our ecosystem grew, so did the disorganization of our documentation.
+
+## What link was that again?
+Let's briefly explain how [docusaurus](https://docusaurus.io/) (the framework we use in our docs) works so you can understand the problem.
+
+In docusaurus, all the pages are written as simple markdown files. These files go inside the `./docs` folder, and can be organized in folders. Each file has a unique ID on its header that identifies it (e.g. `id: what-is`), and this ID, alongside its folder path, is used to generate the URL. 
+
+> For example, the document [`docs/smart-contracts/what-is.md`](https://github.com/near/docs/blob/master/docs/2.build/2.smart-contracts/what-is.md) has the `id: what-is`, so it ends being served in the URL /smart-contracts/what-is.
+
+### The problem
+
+About a year ago, we noticed that our organic growth had left us with a very inconsistent URL structure. Basically, we had a lot of folders, and the files related to the same topic (e.g. NEAR components) would be all over the place.
+
+For example, you would be in the "Build" section reading about "What is a NEAR Component?" and the URL was `/bos/tutorial/quickstart`. The next page was "Setup an Environment" located at `/bos/dev/intro`, followed by "Anatomy of a Component -> State" at `/bos/api/state`. Talk about consistency!
+
+Of course, we did not do this on purpose, it is just how things evolved. You might even notice that we are now talking about "NEAR Components" but the URL talks about "BOS". This is because when we started, "BOS" (Blockchain Operating System) felt like a good name, but community feedback made us know that, indeed, it was not. 
+
+### The migration
+
+We [re-organized more than 200 files](https://github.com/near/docs/pull/1890/files) to a new structure that is more consistent. This makes it easier for users to remember the URLs, improves our SEO, and makes it easier for contributors to find where to add new content. No more need to search across multiple folders trying to find the right file!
+
+In the process, we updated all **internal links**, aided by our [link-checker script](https://github.com/near/docs/blob/master/website/test-links.sh) to make sure we left **no broken links**. We also added **URL redirects** in our server, so all users coming from an external site are redirected to the correct URLs.
+
+Besides checking broken links, we took the time to make sure all the **translations were correctly migrated**. The system Docusaurus uses (called [Crowdin](https://crowdin.com/)) is not very good at detecting changes in a file, so migrating all the translations was a huge effort in itself. 
+
+We could write a blog post just about migrating translations in docusaurus + crowdin... but we will spare you the pain.
+
+<Tip>
+If you come across a URL that is not working, please let us know by using the `Feedback` button on the right side of the page, or by opening an [issue in our repository](https://github.com/near/docs/issues)
+</Tip>
+## What's next
+Now that most of our documentation is in a better shape, we can focus on improving the content itself. We have a lot of ideas on how to make the docs more interactive, and we are excited to start working on them.
+
+Stay tuned for more updates, and remember that if you have any feedback or ideas, you can always reach out to us. We are always happy to hear from you!
+
+See you in the next post! 🚀
diff --git a/blog/2024-05-15-chain-signatures-use-cases.mdx b/blog/2024-05-15-chain-signatures-use-cases.mdx
@@ -0,0 +1,129 @@
+---
+title: "Use cases for Chain Signatures"
+description: "Chain signatures enable you to implement multichain and cross-chain workflows in a simple way. Let's take a look at a few possible use cases"
+date: 2024-05-15
+author: "Damian"
+tags: [docusaurus, updates]
+---
+
+{/* BYLINE:start */}
+_**Damian** · May 15, 2024_
+{/* BYLINE:end */}
+
+*Chain signatures enable you to implement multichain and cross-chain workflows in a simple way. Let's take a look at a few possible use cases*
+
+## Trade Blockchain assets without transactions
+
+Trading assets across different blockchains usually requires using a bridge that supports them, bringing longer settlement times as the trades are not atomic and require confirmation on both blockchains.
+
+Using Chain signatures, you can trade assets across chains simply swapping the ownership of NEAR accounts that control funds on different blockchains. For example, you could trade a NEAR account that controls a Bitcoin account with `X BTC` for another NEAR account that controls an Ethereum account with `Y ETH`.
+
+This way, you can keep native tokens on their native blockchain (e.g., `BTC` on Bitcoin, `ETH` on Ethereum, `ARB` on Arbitrum) and trade them without bridges.
+As an added bonus, trades are atomic across chains, settlement takes just 2 seconds, and supports any token on any chain.
+
+<Tip>
+
+ There are transactions happening on different blockchains.
+ The difference is that a [Multi-Party Computation service](/chain-abstraction/chain-signatures#multi-party-computation-service) (MPC) signs a transaction for you, and that transaction is then broadcast to another blockchain RPC node or API.
+</Tip>
+For example, a basic trade flow could be:
+
+1. Users create an account controlled by NEAR chain signatures
+2. Users funds these accounts on the native blockchains (depositing)
+3. Place orders by funding a new account for the total amount of the order
+4. Another user accepts the order
+5. Users swap control of the keys to fulfill the order
+
+![docs](/assets/blog/native-cross-chain.png)
+
+<details>
+- User A has `ETH` on the Ethereum blockchain, and wants to buy native Bitcoin
+- User B wants to sell Bitcoin for Ethereum
+
+**Steps**
+
+1. User B, using NEAR, creates and funds a new account on Bitcoin with 1 `BTC`
+2. User B, using the spot marketplace smart contract, signs a transaction to create a limit order. This transfers control of the Bitcoin account to the smart contract
+3. User A creates a batch transaction with two steps
+    - Creating and funding a new Ethereum account with 10 `ETH`
+    - Accepting the order and atomically swapping control of the accounts
+4. User A takes ownership of the Bitcoin account with 1 `BTC`, and User B takes ownership of the Ethereum account with 10 `ETH`
+5. User A and B can _"withdraw"_ their asset from the order by transferring the assets to their respective _"main"_ accounts
+</details>
+
+---
+
+## Oauth-controlled Blockchain accounts
+
+On-boarding is a huge problem for decentralized applications. If you want widespread adoption you can't expect people to keep seed phrases safe in order to use an application.
+
+An attractive way of managing Web3 accounts is to use existing Web2 accounts to on-board users. This can be done in the following way:
+
+1. Deploy a NEAR contract that allows the bearer of a user's [JWT token](https://jwt.io/) to sign a blockchain transaction (Ethereum, Polygon, Avalanche, and others)
+2. The user validates their identity with a third-party receiving a JWT Token
+3. The user holding that token can interact with blockchain applications on Ethereum/Polygon/+++ via the NEAR contract for the duration of its validity
+
+Any method of controlling a NEAR account can also be used to control a cross-chain account.
+
+<Info>
+JSON Web Tokens are a standard RFC 7519 method for representing claims securely between two parties. They are used in this example to represent the claim that someone is the owner of an Oauth account.
+</Info>
+---
+
+## Cross-chain Zero-friction onboarding
+
+Using unique features of the NEAR account model, [Keypom](https://docs.keypom.xyz/) provides zero-friction onboarding and transactions on NEAR. They are generally used for NFT drops, FT drops, and ticketing.
+
+A generic Keypom user-flow could be:
+
+1. The developer creates a restricted NEAR account
+2. The account is funded with `NEAR`
+3. The user receives a key with limited control of the account
+4. The user uses the funded account to call controlled endpoints on NEAR
+5. The user returns the remaining funds to the developer and their account is unlocked
+
+<Tip>
+This allows easy onboarding to decentralized apps. The accounts are initially restricted to prevent the user being able to simply withdraw the `NEAR` from the account.
+</Tip>
+## DeFi on Bitcoin (and other non-smart contract chains).
+
+Using chain signatures, smart contracts on NEAR can control externally-owned accounts on non-smart contract chains like Bitcoin, Dogecoin, XRP Ledger, Bittensor, Cosmos Hub, etc. This enables developers to use NEAR as a smart contract “layer” for chains that do not support this functionality natively.
+
+For example, a developer can build a decentralized exchange for Bitcoin Ordinals, using a smart contract on NEAR to manage deposits (into Bitcoin addresses controlled by the contract) and to verify and execute swaps when two users agree to trade BTC for an Ordinal or BRC20 token.
+
+Example:
+1. Seller generates a deposit address on Bitcoin that is controlled by the marketplace smart contract on NEAR via chain signatures
+2. Seller deposits a Bitcoin Ordinal to the deposit address
+3. The Ordinal is listed for sale with a price and a pre-commitment signature from the seller
+4. Buyer accepts the order, deposits USDC
+5. The control of the Bitcoin Ordinal address is given to the buyer, USDC on NEAR is transferred to the seller
+
+#### Using Chain Signatures
+
+With Chain Signatures you can do the same but across many chains, for example Polygon:
+
+1. The developer creates a restricted NEAR account with a key
+2. The account is funded with `NEAR` and `MATIC`
+3. The user receives a key with limited control of the account
+4. The user uses the funded account to sign payloads calling controlled endpoints on Polygon
+5. The user returns the remaining funds to the developer and their account is unlocked
+
+This allows developers to pay for users to use arbitrary contracts on arbitrary chains.
+
+---
+
+## Decentralized Clients
+
+A big problem in decentralized applications is that while the smart contracts are tamper-proof, the clients that access them generally are not. This allows practically complete control over any user account provided they are using the frontend assets that you serve. This has security, trust, and regulatory implications.
+
+When smart contracts can sign payloads you can start using [signed exchanges](https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#name-introduction) (or polyfills) to require HTTP exchanges to be signed by a certain key. If it is not signed with this key the SSL certificate is considered invalid. This means that individual users cannot be served invalid frontends without it being generally observable and non repudiable.
+
+---
+
+## Communication with private NEAR Shards
+
+Companies like [Calimero](https://www.calimero.network/) offer private NEAR shards. Currently, sending messages to and from these NEAR shards is troublesome. If each shard had the ability to sign their message queues, they could be securely sent from one shard to another. Thus you could communicate bidirectionally with any shard as easily as you can with a contract on your own shard.
+
+<Tip>
+This could also simplify NEAR's sharding model, by treating each NEAR shard like one would a private shard.
+</Tip>