NDNA 2 - What Comes After Abstraction: Trade-Offs and Tooling for the Next Era

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:05

   Hello. 2 00:00:06,000 --> 00:00:09,104.00000000000182 It's July 25th, 2025, and this is nDNA. 3 00:00:10,000 --> 00:00:15,248.00000000000182 Continuing the discussion from last week, Near's developer ecosystem has distinctly crossed a threshold. 4 00:00:15,799 --> 00:00:20,720.0000000000036 Developers are better at understanding that complexity should be hidden behind great user experiences.

2. 0:21

   But it's not enough to hide complexity behind enigmatic abstractions. Real world problems, such as censorship risk, on-chain automation, tokenomics, volatility, and crushing UX, demand surgical solutions that inevitably introduce new trade-offs.

3. 0:38

   In this piece, we'll examine 3 news stories that highlight emerging frontiers. From forced inclusion of transactions, autonomous on-chain agents, and usage linked emissions, and make the case that each solves this puzzle by shifting complexity to a new layer, which Near can provide.

4. 0:56

   From chunk producers to validators, the forced inclusion NEP. 10 00:01:01,186 --> 00:01:05,135.99999999999272 So imagine Near as a vast, ever-glow-growing library. Its ledger is divided into many sections or shards, each curated by a rotating librarian known as the chunk producer.

5. 1:13

   In theory, handing off the reins every week should prevent any single person from shelving or shelving aside your new book or transaction forever. 13 00:01:26,419 --> 00:01:40,783.9999999999854 But in practice, if this week's librarian doesn't care for your book, it can languish in limbo until their shift ends, leaving your book transaction and your application in an agonizing state of uncertainty.

6. 1:41

   Ilia summed this up really well on Twitter and X saying that Near can actually support FOCIL or F-O-C-I-L very easily by allowing stateless validators to attach transactions to their approvals. Given now running a validator is only $27 a month through Meta Pool, this allows potentially a wide variety of parties to ensure censorship resistance even if regular chunk production is professionalized. 16 00:02:10,979.0000000000146 --> 00:02:16,848 What that means is that the forced inclusion proposal re- is rewriting the rule book here. 17 00:02:17,419 --> 00:02:29,136.0000000000291 Instead of entrusting each shard's fate to a lone chunk producer, every validator on duty now carries a tiny include these transactions list when they cast their approval vote.

7. 2:29

   A block is only considered valid once the majority of validators have mutually agreed to include every transaction in the combined list. In other words, no single node can veto your valid transaction once enough of the committee has signed it and it belongs to the next block. 20 00:02:45,299 --> 00:02:55,152.0000000000291 Under forced inclusion, chunk producers still would propose and sequence transactions, transactions, but they would no longer wield ultimate discretion over inclusion.

8. 2:55

   Stateless validators step in and sign off to enforce the inclusion list, verifying that each requested transaction appears in the proposed block before signing. 22 00:03:06,979 --> 00:03:20,176.0000000000291 To keep overhead manageable, each list is deliberately small, perhaps capped at 8 transactions per approval, uh, to be bounded by gas costs and the whole total byte footprint.

9. 3:21

   This simple guardrail transforms the approval process into a collective check rather than a lone gatekeeper's whim. Again, this is a abstract concept. It was nothing that's an actually threat right now, but ultimately forced inclusion layers the minimal yet powerful check on Near's existing approval votes.

10. 3:41

    It eliminates the single producer veto that can still, that can actually stall a valid transaction indefinitely while embedding transparency into the process. 27 00:03:50,914 --> 00:03:57,968.0000000000291 Hence, developers know at a glance which transactions were held back and by whom rather than overhauling Near's architecture.

11. 3:58

    Forced inclusion invites the community to build visibility and guardrails around the mechanisms of decentralization itself. After all, true, true censorship resistance isn't actually magic. Uh, it's a system of checks, balances, and then you need a dashboard that ties it all together to see what's going on here.

12. 4:17

    The question, though, that needs to be asked is who will benefit from this, this? What 33 00:04:24,179 --> 00:04:30,32.00000000005821 When the focus is on these type of proposals, are they benefiting the network more than actually working on products?

13. 4:31

    For example, is this something where we need to be spending mindshare on this or is this something that can actually kind of wait a little bit further down the road? I don't know the answer to that, but it's something to consider when we see these type of proposals. Next is shade agents from cron jobs to agent sprawl.

14. 4:53

    This week we hosted a workshop on shade agents on DevHub Live, which is available on the d- Near DevHub YouTube channel. And as we consider this new primitive of shade agents, I believe there are opportunities on 2 fronts for developers.

15. 5:09

    Shade agents are a radical new primitive, fully on-chain bots that observe events, make decisions, and sign transactions without a single off-chain cron job. Instead of renting servers or stitching together cloud functions, developers can encode autonomous logic directly into Near's contracts.

16. 5:27

    Shade agents aren't just a nicer SDK, it's a fundamentally different way to think about application architecture. Microservices, but on chain. Yet with this power comes a new challenge. Every little task, price monitoring, treasury balancing, proposal polling, gets its own standalone agent.

17. 5:46

    You end up with a dozen of tiny contracts, each juggling state gas and failure logic. 46 00:05:52,619 --> 00:06:02,544.0000000000582 What started as an elegant centralized autonomy, automation quickly now starts to resembles a tangled mess of microservices whose interactions are unpredictable and uncontrollable.

18. 6:03

    The fan of architecture of microservices for everything kinda came and went and, but for some, it did stay. And those that kept it needed to be able to be supported by orchestration layers. That tension with shade agents, however, is a golden opportunity.

19. 6:22

    What the ecosystem needs now is an orchestration layer, a master agent framework that treats shade agents like pods in a con- container cluster. Imagine a lightweight on chain coordinator that batches 10 child agent actions into a single transaction to save gas, uh, enforces ordering so price updates always precede portfolio judgment, adjustments, and automatically retries failed calls.

20. 6:45

    Rather than each agent reinventing its own dispatcher, they could actually register with a shared scheduler, declare the dependencies, let the orchestrator manage the execution. Building such a platform would unlock a new class of decentralized applications.

21. 6:59

    You can drop in ready-made agents for everyday tasks such as liquidity management, token investing, and airdrop distribution, and focus on your unique logic. 56 00:07:08,739 --> 00:07:14,352.0000000000582 Permissioning and gas budgets could then be handled once by the orchestrator rather than coded into every agent.

22. 7:15

    Dashboards could then even visualize a single execution graph instead of a dozen independent logs. In short, shade agents gives us the what, autonomous on chain actors. Now it's up to us as developers to invent the how, the orchestration framework that transforms potential chaos into a cohesive, predictable, and gas-efficient automation ecosystem. 60 00:07:36,639 --> 00:07:44,912.0000000000582 Whomever builds that layer first will define how near applications scale in the era of on chain autonomy.

23. 7:46

    Dynamic incentives tying inflation to real demand. As of now, the Near community is actively voting on a proposal that would cut the protocol's annual inflation rate from 5% to two and a half percent overnight. Supporters frame this move as a milestone in Near's economic maturity, a way to protect fiscal discipline and long-term sustainability.

24. 8:06

    While the proposal and discussion highlight notable benefits, some key points are missing. Even if the proposal passes, this halving would be largely symbolic. It temporarily resets the supply curve without addressing the more profound structural disconnect between token, token issuance and actual network activity.

25. 8:31

    The core issue is that inflation on Near would still proceed at a fixed predetermined rate. The vote lowers that baseline from which issuance continues to grow, but there's no built-in mechanism to link the inflation rate to the network usage.

26. 8:45

    Whether transaction volume explodes or plummets, whether the ecosystem is flourishing or stagnating, tokens continue to be minted at the same pace. At one t- at one time adjustment doesn't actually in- introduce flexibility, it merely delays the next decision until the community votes again.

27. 9:05

    This governance-led approach introduces several challenges. 72 00:09:09,719 --> 00:09:14,671.9999999998836 first, the protocol resumes linear growth immediately after the cut. Token issuance continues at the rate of two and a half percent annually, regardless of t- real-time usage, creating a situation where monetary expansion is insensitive to on chain conditions.

28. 9:26

    If network usage surges tenfold, inflation doesn't increase much to match developer contributions and becomes deflationary, which actually could be a good thing. If usage though collapses, inflation doesn't shrink to preserve value. The issuance schedule remains blind to the network's actual health.

29. 9:47

    second, this mechanism is fundamentally governance-driven. It's not usage-driven. 79 00:09:52,619 --> 00:10:01,455.9999999998836 Inflation adjustments only occur when stakeholders organize, debate, and vote, processes that can take months and are influenced by human coordination dynamics, not real-time data.

30. 10:02

    As a result, monetary policy becomes reactive and episodic rather than adaptive. By voting on this one-off reduction, the community sets a precedent that economic tuning must be a manual, slow, and subjective to political choices rather than automatic responsiveness.

31. 10:19

    More importantly, this approach lacks a feedback loop. Because inflation is decoupled from usage signals, such transaction volume, active addresses, and fee burns, there's no systematic way for the protocol to adjust its issuance based on demand.

32. 10:34

    Monetary policy is left untethered from network fundamentals, turning supply decisions into calendar events rather than performance metrics. A more transformative path would involve usage-linked emissions, minting new tokens in proportion to real measurable demand on the network instead of adhering to a fixed annual rate.

33. 10:55

    Inflation would become a dynamic function of network activity when usage surges more than uses- users, transactions, and fees. And issuance would naturally slow to reduce cell pressure. When usage drops, inflation could gently rise to provide incentives for builders and validators who continue to contribute during leaner times.

34. 11:20

    Regardless of the approach, this adaptive model offers 3 key benefits. first, it aligns token supply with actual utility, meaning contributors are rewarded when their efforts coincide with real demand. second, it stretches the emissions budgets further as tokens are only created when the network justifies it. 92 00:11:38,114 --> 00:11:45,584.0000000001164 third, it introduces self-regulation to the system, smoothing out boom and bust cycles that rigid schedules can amplify.

35. 11:46

    Of course, this approach is not without its complexities. Curating a robust usage oracle would require aggregating reliable on-chain data every epoch, defending against manipulation through multi-node signing or stake weighted reporters, and using moving averages to smooth out volatility. 95 00:12:01,999 --> 00:12:10,526.0000000001164 The formula that governs issuance adjustments would need to be transparent and predictable, and token holders must retain the ability to override it in extreme scenarios.

36. 12:11

    Still, the promise of usage-linked emissions is compelling. It transforms governance from a series of occasional interventions into a system of continuous alignment. By anchoring inflation to the network's actual heartbeat rather than a fixed calendar, NEAR would actually move closer to an economically sustainable model, one that represents in real time to the needs of its builders, users, and infrastructure.

37. 12:32

    I think this is an interesting place for NEAR to possibly experiment. I don't know if these economic policies would be better or worse or whatever it might be. But if you're looking to actually build real world products and you want to have long term- long term sustainability, thinking outside of the normal way of just saying, We have to do emissions like this, or, You have to do things like that, sometimes puts you into a box that does not actually fit what is needed to actually be a viable product long term. 102 00:13:01,979 --> 00:13:08,459.0000000001164 It's something to consider, and it's something that the discussion hopefully will have in the future beyond just this vote. 103 00:13:08,459.0000000001164 --> 00:13:13,616 NEAR's evolution from a research playground to a production ecosystem is both exhilarating and sobering.

38. 13:14

    Forced inclusion, shade agents, and user-lint emissions each tackle a pressing challenge, but they also introduce fresh vectors for risk, complexity, and opacity. The questions we face aren't merely technical. They're architectural and they're ethical. 107 00:13:28,699.0000000001164 --> 00:13:30,339 Where do we place our trust? How do we strike a balance between user convenience and transparency?

39. 13:33

    What guardrails will prevent innovation from outpacing safety? The future of NEAR is bright. However, brightness can blind us if we don't actually remain vigilant to the trade-offs. Could the next chapter be written not as passive adopters, but as active stewards, crafting the guardrails that turn in- innovation into enduring censorship-resistant, scalable, and transparent building blocks?

40. 13:54

    If you liked this issue of nDNA and would like to see more, make sure you subscribe. Please share and like so these- this future episodes as well. Thank you.