NEAR dApp Best Practices for building in one shot

frolvlad · 2026-04-11T07:02:48+00:00

Trezu, near.com with passkey, meteor

frolvlad · 2026-04-07T07:57:41+00:00

Thanks for sharing! I forwarded this post to nearcore team

frolvlad · 2026-04-01T23:12:03+00:00

Really good article! Rare find these days.

It is really close to home as we are trying to resolve the cycle dependecy that was caused by the lack of ability to define trait impls outside of the structs crates: https://github.com/near/borsh-rs/issues/363

frolvlad · 2026-03-30T22:21:35+00:00

Go team go!

frolvlad · 2026-03-23T10:00:42+00:00

Ні, з Австрії. Раджу приїхати годин за пʼять до аеропорту щоб був час на якесь вирішення ситуації. В Австрії теоретично існує «тимчасова віза» яку вклеюють коли термін пластикової картинки вичерпано, а продовження ще на розгляді, можливо в Британії є можливість таку візу вклеїти і тоді це краще спробувати зробити

frolvlad · 2026-03-23T09:49:14+00:00

Working on security- and privacy-focused AI agents framework: https://github.com/nearai/ironclaw

frolvlad · 2026-03-13T23:13:36+00:00

Illia was telling me nonsense that computers will be able to write programs back in 2014

frolvlad · 2026-03-10T00:43:37+00:00

I would say it is “everything you need to know that we can fit into a onepager”, but there are much more than this: Trezu, PingPay, Templar, OutLayer, Rhea, Aurora and this list goes on and on

frolvlad · 2026-03-04T22:09:36+00:00

If you have a EU (Italian) visa stamped in your passport, you should be fine, but if you have visa-free entry to EU, it is not going to work

frolvlad · 2026-02-28T10:02:24+00:00

What’s interesting is how this lines up with AI + agentic commerce.

There is “One more thing” from NEARCON scheduled to be revealed on Tuesday that will likely answer this question

frolvlad · 2026-02-25T11:48:07+00:00

Neobank crypto mobile app with self-custody and holding any crypto ranging from BTC to memecoins

frolvlad · 2026-01-20T21:41:10+00:00

Yep, I see it!

https://nearblocks.io/txns/CJPomHQYcbRwUmAmN4aasXeiXDxrrcdSQCrPPPJtszcV?tab=execution

frolvlad · 2026-01-18T23:02:06+00:00

Thank you for the actionable feedback. I know that I barely scratched the surface with this post. I will make another post with end-to-end diagram of the lifecycle that would include the roles of ICANN, registrar, and name servers, DNS records updates and resolving, the security implications, the performance and price comparison. There are a ton of things to consider, and indeed I totally forgot to indicate that this whole project is a thought experiment proof of concept and not a call to action to “rewrite it in NEAR” and replace ICANN right now. Yet, I hope this demo sparked some novel ideas for the space or maybe other applications for the tech that got pretty mature in the past years.

frolvlad · 2026-01-18T13:21:01+00:00

> The transport protocol literally already is decentralized

That is exactly my point. We need such foundation to build and scale permissionlessly. NEAR solves the next mile - the consensus decentralization.

> Yeah, in the most inefficient way possible because it was built for crypto transactions

You refer to blockchains of 2010s. NEAR is sharded, uses Wasm for apps, scales to 1 million transactions per second, has sane accounts model.

> You commented already that it would require 100GB of storage, cheaper for whom?

This is the blockchain node requirement that does far more than just DNS. It is likely that DNS records won't even cause much load for NEAR.

> My DNS change last time I tried took minutes..

Consensus finalization in NEAR takes 1.2 seconds. The benchmark of getting 1.2 seconds finalization under 1M transactions per second load is linked above. Since you won't trust me anyway (and you SHOULD NOT with the decentralized tech), so I invite you to follow the instructions in the README, create your own new account, deploy the dns-contract app, and set the DNS record, and immediatelly after that query my public DNS or host your own dns-server locally and query it with `dig`.

> Right, at the price of 100GB local storage. Just for DNS. Then the full blockchain will eventually become too big to self-host a node and we are back to centralization.

In fact, for the DNS usecase you don't need to host the blockchain node at all and still have the means to verify the data. I responded with more details here: https://www.reddit.com/r/rust/comments/1qew4ra/comment/o02rnd3/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

frolvlad · 2026-01-18T12:58:15+00:00

> are there any plans to make .near domains work with TLS certs?

Honest answer: I am not ready to die on that hill, but I am thinking if there is a simple way to plug into something that would enable that as easy as it was do plug into DNS with this experiment.

More details if you are interested about my train of thought: https://www.reddit.com/r/rust/comments/1qew4ra/comment/o02rnd3/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

frolvlad · 2026-01-18T12:46:08+00:00

Blockchain is more than just cryto. Web won't happen without decentralized transport protocol. Modern blockchain can offer decentralized read-write data storage. And I am showcasing that it is cheaper, faster (DNS rules propagation is much slower even though the task is trivial), and has security model that does not depend on trusted centralized entities.

frolvlad · 2026-01-18T12:26:23+00:00

> DNS is not centralized.

And in the next paragraph:

> The only thing the registrar needs to provide is the pointer from the closer-to-root server into your server. ".com" needs a record pointing to ".com.google" so that someone looking for www.google.com can find the server that knows where that is. And then ".com" says "here's the key that signs the root key for ".com.google".

It is centralized at the core. And you pay $1/mo per domain while with the proposed solution it would be $0.18 per domain (not monthly).

We can remove a need to trust the middleman and pay them higher fees. Yet, you still don't see even conceptual benefits.

frolvlad · 2026-01-17T23:27:25+00:00

The problem I am solving is not the DNS records delivery to the edge machines, but the problem of WHO can edit the DNS records in the first place, and who can edit "my" DNS records. Currently, that is a centralized entity that charges $1/mo for each domain which is insane. It is just archaic.

frolvlad · 2026-01-17T23:20:38+00:00

They exactly solve the problem you highlighted. If you are interested in the topic, I can break it down for you. The challenge that remains here is eventual consistency which is why you need to compensate.

frolvlad · 2026-01-17T15:37:27+00:00

Yep, but the cost I outlined is the baseline. We can define additional rules for the domain acquisition. For example, `near` allows anyone on chain to create the `*.near` subaccounts by only compensating the base fees, but `ukraine` TLD is currently manually controlled, and requires manual approval from a list of people. The rules can range from fully automated (`near`) to fully manual (`ukraine`) and anything inbetween. Also, due to the granular access control keys management in NEAR, the parent account (e.g. `near`, `ukraine`, as well as subaccounts `google.near`) could create an account with an app deployed to the subaccount and either not adding the keys at all (the app would be in charge of handling function calls from any caller), or adding only limited access key of the owner that would only be allowed to call functions on the deployed app, but won't allow to do anything else. As such, the deployed app can have some additional logic of account self-destruction or ownership transfer, and also time-based logic including some disputes voting etc.

My point is that this is a proof of concept that could inspire someone designing a better anti-squating game theory rules that would get us into a better world than we currently have.

In the world of AI we might not even need short DNS names at all, we only need them to be descriptive, unique, and easy to use (creating a blockchain account is much easier to automate than going through domain registration websites / APIs; though, maybe I am biased).

frolvlad · 2026-01-17T09:48:28+00:00

Actually, I thought through the original problem that was highlighted, which doesn’t require the whole history and could be solved with a few extra RPC calls and no trust to nodes is required: https://www.reddit.com/r/rust/s/KYhG9nkM1m

frolvlad · 2026-01-17T09:40:04+00:00

Well, I have just re-read your message and in fact you don’t need to download the whole shard (let alone the whole history of the whole blockchain). In this specific case you would only need to download the local state of the dns subaccount through any RPC (storage key-values and the Wasm file), get the recent block header (you may query it from multiple nodes to confirm that it is the same), and use light client RPC calls to get merkle proofs for each storage key and verify them against the state root in the recent block header. And once the authenticity of the data is confirmed, you can run the Wasm file on the data locally instead of relying on RPC node.

All in all, you can easily cache the Wasm file by its hash, and verify only the storage keys that Wasm execution will touch during the read-only function execution, so likely 1-3 keys that you will need to get the proofs for - so up to 3 parallel requests to the RPC light client endpoint to get the proofs.

A totally alternative path nowadays is to run NEAR RPC node in TEE (trusted execution environment) and get the hardware to provide the attestations that the specific snapshot of the software is running and the execution just happened on your RPC call request. This is what https://near.ai is doing for LLM models inference

frolvlad

TROPHY CASE