Neurons and Voting: How the NNS Really Works

The moment our team truly understood the Network Nervous System wasn’t when we staked our first ICP, but when we watched a proposal to upgrade a subnet’s replica version pass, and then saw the entire Internet Computer Protocol shift automatically, without a single person touching a server. The NNS isn’t just a staking mechanism — it’s a living, breathing governance organism where your neuron’s voting power directly shapes the ICP roadmap. That realisation changed how we look at every neuron, every dissolve delay, and every single vote cast at the ICP Community Conference and beyond.

What Exactly is an ICP Neuron?

A neuron is the heart of your voice in the DAO. When you lock ICP tokens inside a neuron, you’re not just parking capital for passive yield — you’re creating a governance unit that carries voting power. The minimum ICP stake to create a neuron is 1 ICP, a deliberately low barrier that keeps the system inclusive. But what you do with that neuron, how long you commit, and how actively you participate transforms it from a simple lockup into a power lever within the Internet Computer Protocol’s ecosystem.

We often explain neurons as your on-chain identity for decision-making. The tokens remain under your control, but they become an instrument that lets you vote on every proposal the NNS processes, from protocol upgrades to treasury disbursements for events like the ICP Community Conference.

Liquid ICP vs. Staked Neurons: The Fundamental Difference

Liquid ICP sits in your wallet, instantly tradeable, transferable, useful for canister cycles and DeFi. A staked neuron, by contrast, deliberately sacrifices that liquidity. Inside the neuron, your ICP is locked and generates voting power, but you cannot sell or move it without first dissolving the neuron — a process that can take weeks or years depending on your settings. That trade-off is exactly what makes governance meaningful. If everyone could instantly exit, votes would be speculative. The dissolve delay creates commitment.

Our team sees liquid ICP as the fuel for applications, while neurons are the steering wheel. Holding both lets you participate in the economy and the governance of the Internet Computer Protocol simultaneously.

Dissolve Delay and Age: The Twin Pillars of Voting Power

Voting power comes from two variables inside every neuron. Dissolve delay is the time you set for the neuron to release its stake once you initiate dissolution — from zero up to a maximum of 8 years. The longer the delay, the higher the voting power multiplier, reaching a 2x bonus at the maximum 8-year mark. Age, meanwhile, rewards patience: the longer a neuron has been locked and not dissolving, the more its influence grows, up to a 1.25x age bonus. Together, a neuron with an 8-year dissolve delay and significant age can wield up to 2.5x the base voting power of its staked ICP. We often remind newcomers that these mechanics ensure the loudest voices belong to those with the most skin in the game — exactly what the NNS was designed to protect.

The Network Nervous System as the Ultimate DAO

When we call the NNS the ultimate DAO, we’re not exaggerating. It runs entirely on-chain as a seamless part of the Internet Computer Protocol, handling everything from elections to code updates without any off-chain committee or manual multisig. The NNS is the decision-making backbone that holds the whole network together, including the funding and direction of community touchpoints like the ICP Community Conference. Every neuron in the system collectively controls the Internet Computer’s future.

How Proposals Move from Submission to Execution

A proposal starts when an entity — sometimes the DFINITY Foundation, sometimes a community member — submits it to the NNS. It immediately enters a voting period where neurons cast their ballots. The system tallies votes constantly, applying power bonuses in real time. If the proposal reaches the required majority before the expiry, it passes. What floors our team every time is what happens next: the NNS executes the approved proposal entirely on-chain without human intervention. If the proposal alters a system parameter or upgrades a subnet’s protocol, the change deploys autonomously. No one clicks a deploy button; the code-ruled machine simply acts.

Why Our Team Calls the NNS a ‘Code-Ruled Governance Machine’

We coined the phrase ‘code-ruled governance machine’ because the NNS removes human discretion from execution. There are no admins overriding votes, no emergency pauses the foundation can push unilaterally. The rules live in the NNS canisters, and each action — reward distribution, neuron spawning, proposal execution — follows the protocol’s logic. That’s a radical departure from typical DAOs that rely on multi-sigs and off-chain social consensus. For ICPCC attendees who ask us how much trust they should place in governance, we point to that autonomous execution: trust isn’t needed because the code enforces the outcome.

How Voting Rewards Accumulate in the UK

Every day the NNS mints new ICP to reward neurons that have voted on proposals. Those rewards land as maturity — a percentage added to your neuron that can be spawned into a new liquid neuron. It’s a compounding system that incentivises consistent participation. For UK residents, however, there’s an important tax nuance: HMRC treats staking rewards as miscellaneous income upon receipt for UK taxpayers. The fair market value of the rewards at the moment they become available needs to be included on self-assessment tax returns. Our team always recommends keeping a clear daily record of maturity increments so you can report accurately without scrambling at year end.

Manual Voting vs. Following Other Neurons

You don’t have to review every proposal yourself. The NNS lets you follow other neurons, essentially delegating your voting power to a trusted topic expert. Many UK participants choose to follow the DFINITY Foundation as a prominent neuron provider, especially on technical subnet management topics, while manually voting on governance or treasury proposals they’re passionate about. Following doesn’t lock you in; you can override any vote manually. This flexibility is what makes the system approachable.

Calculating Your Daily Maturity and Spawning New Neurons

Maturity accrues daily based on your neuron’s voting participation and its relative voting power to the total. You can see your maturity as a percentage inside the NNS front-end dapp. Once it reaches at least 1 ICP worth of maturity, you can spawn it into a separate neuron, which then begins its own dissolve delay journey. The spawned neuron starts with zero age, but you can immediately set its dissolve delay, start earning rewards, and even combine it back into your main neuron later. We’ve found that regularly spawning and re-staking is a powerful compounding habit, as long as you keep UK tax obligations in mind when those new ICP tokens become available to you.

Choosing a Voting Strategy That Matches Your Convictions

Every neuron holder faces a choice: passive delegation or active hands-on review. There’s no universally correct answer, but the path you pick shapes the DAO. If everyone delegated and never reviewed, governance would consolidate. If everyone voted manually on every detail, participation would be exhausting. A healthy balance — actively monitoring topics you know well and following trusted entities on the rest — is how many of us at the ICP Community Conference approach it.

The Radical Difference Between ‘Follow’ and ‘Manual’ Voting

Manual voting means you personally read each proposal and cast your ballot. Your neuron then records that explicit choice for that topic. ‘Follow’ is more subtle: you select a known neuron (the DFINITY Foundation’s neuron is a popular pick) and assign it to specific proposal topics. When a proposal arises in that topic, your neuron automatically votes identical to the followed neuron, unless you intervene. The radical difference lies in responsibility — manual voting keeps all power with you, while following distributes it. Both are essential tools, and the ability to mix them is what makes liquid democracy on the Internet Computer Protocol so resilient.

Liquid Democracy in Practice: Hot-Keys and Neuron Management

Managing a neuron securely doesn’t mean keeping your main seed phrase on a daily-use machine. The NNS supports hot-keys — auxiliary keys that can vote and perform non-critical operations without the power to disburse the stake. Our team sets up hot-keys for regular voting while the neuron’s controlling key remains in cold storage. This lets us participate actively in governance, including the informal discussions that happen around the ICP Community Conference, without compromising security. It’s a practical pattern that more neuron holders are adopting as ICPCC grows and more proposals require attention.

The 8-Year Neuron and Why Dissolve Delays Matter

The maximum dissolve delay bonus for voting power is 8 years, and committing to that length is the strongest signal of long-term alignment possible. When you set an 8-year delay, your voting power doubles, and you position yourself at the highest tier of influence. The act of locking for nearly a decade tells the entire DAO — including fellow voters at the ICP Community Conference — that you’ve got genuine skin in the game. It’s a beacon of conviction, not a get-rich-quick scheme.

Dissolving, Non-Dissolving, and the ‘Stop Dissolving’ Toggle

A dissolving neuron counts down its delay toward zero, bleeding voting power as it goes. A non-dissolving neuron holds its delay constant, preserving full influence. The ‘stop dissolving’ toggle is your emergency brake; hit it, and the countdown halts, locking in the current delay. That toggle gives you the flexibility to change your mind without completely exiting governance. For instance, you might set a neuron to dissolve for a year while you reassess, then stop dissolving at 6 months if you decide to remain fully engaged. Age, however, resets to zero once you start dissolving, which is a key trade-off we always highlight.

How an 8-Year Delay Maximises Your Voting Rewards and Influence

Because voting rewards scale with voting power, an 8-year delay not only doubles your weight but also increases the daily maturity you earn. Combined with the age bonus, you can receive far more daily ICP than a shorter-delay neuron of the same size. This means that over a long horizon, long-term stakers disproportionately shape the Internet Computer Protocol’s roadmap and treasury decisions. It’s a design that deliberately rewards patience and conviction, and it’s why many of our team members have personally committed to maximum-delay neurons — it aligns our voice with the network’s multi-decade vision.

Participating in NNS governance is the most direct way to influence the Internet Computer’s future. Every vote cast through your neuron, whether you’re manually scrutinising a subnet upgrade or following a trusted voice on treasury matters, ripples into the autonomous execution of the world’s most advanced DAO. From setting an 8-year dissolve delay to discussing voting strategies at the ICP Community Conference, each action strengthens the entire ICPCC ecosystem. The power isn’t theoretical — it’s coded, instant, and waiting for your neuron to step into the loop.

Frequently Asked Questions

Do I need to vote on every single proposal?

No. You can follow other neurons on topics you don’t want to review manually, and your neuron will cast the same vote automatically. You’re free to override any following decision at any time. What matters is that your neuron participates, so your stake actively contributes to governance even if you delegate on a few topics.

How are voting rewards calculated, and when do I receive them?

Rewards are minted daily and appear as maturity on your neuron. The amount depends on your neuron’s voting power (staked ICP plus dissolve delay and age bonuses) relative to the total voting power that voted on proposals that day. Maturity accrues as a percentage and can be spawned into liquid ICP once it represents at least 1 ICP worth of value.

What happens if I start dissolving my neuron?

Once you start dissolving, the dissolve delay countdown begins, and your voting power reduces daily toward the base staked ICP value. Your age bonus also drops to zero. You can stop dissolving at any point to freeze the remaining delay and preserve influence, but age will start rebuilding from scratch.

How does HMRC treat ICP staking rewards for UK taxpayers?

HMRC treats staking rewards as miscellaneous income upon receipt. You need to note the fair market value in GBP at the time the maturity becomes available and include it on your self-assessment tax return. Keeping a daily log of maturity accumulation helps make reporting straightforward.

Can I increase my dissolve delay after creating a neuron?

Yes. You can increase the dissolve delay at any time, up to the maximum 8 years. Increasing the delay immediately boosts your voting power multiplier. The only restriction is that you cannot decrease the delay except by starting the dissolving process, which then counts down over the set period.

Reading Protocol Documentation Efficiently: Our Team’s Approach

We used to dread opening protocol documentation. It felt like stepping into a maze where every corridor led to three more corridors, and the map was written in a language we half-understood. That changed once our team developed a system that turns dense technical specs into actionable understanding. Now, when we sit down with Internet Computer Protocol documentation to prepare for the ICP Community Conference or to design a new DAO interaction, we follow a repeatable process that saves hours and reduces the mental fatigue that used to send us reaching for yet another coffee. Here’s exactly how we do it.

Why Most Developers Struggle with Protocol Documentation

We’ve watched talented developers hit the same wall repeatedly when approaching Internet Computer Protocol materials. The friction isn’t usually about intelligence or experience. It’s about the mismatch between how protocol documentation is organised and how our brains naturally seek information. The DFINITY Foundation has produced remarkably thorough resources, but thoroughness brings its own challenges.

The paradox of comprehensive documentation

Comprehensive documentation sounds like a pure positive, and in many ways it is. The Internet Computer Protocol ecosystem has detailed specifications covering everything from chain-key cryptography to canister lifecycle management. The problem we kept encountering was that comprehensiveness creates an entry barrier. When every page links to five more pages that each link to five more, you quickly lose the thread. Our team realised we were spending more time managing navigation decisions than actually absorbing concepts. The documentation was exhaustive, but our reading strategy was exhausting.

How traditional reading habits fail with technical specs

Most of us learned to read linearly: start at page one, continue until the end. That habit actively works against you with protocol documentation. The Internet Computer Protocol docs aren’t structured as a narrative; they’re structured as a reference. Reading the Network Nervous System specification from top to bottom, for example, mixes governance philosophy, message routing details, and cryptographic proofs in a sequence that makes sense for lookup but not for learning. We had to unlearn our default reading mode before we could make real progress.

Pre-Reading: Setting Your Learning Objectives First

The single biggest shift our team made was refusing to open a single documentation page until we had written down exactly what we needed to learn. This sounds almost too simple to matter, but it transformed our sessions from meandering research marathons into focused extraction missions. When we prepare content for the ICP Community Conference or design DAO tooling, we now spend ten minutes framing questions before we spend an hour hunting answers.

Defining your purpose before you open a single page

We keep a running document where every documentation session begins with a purpose statement. Some examples from recent weeks: “Understand exactly how canister controllers are assigned during SNS initialisation” and “Find the precise mechanism by which NNS proposals reach consensus.” These are specific enough that we know when we’ve answered them. Vague goals like “learn about the Internet Computer” lead to vague results. We write the question at the top of our notes and refuse to follow tangents until the primary question has a satisfactory answer.

Mapping documentation structure to your project needs

Before diving in, we take five minutes to scan the documentation’s information architecture. The Internet Computer Protocol docs are organised into distinct sections: core protocol, canister development, tokenomics, governance. Knowing which section likely holds our answer prevents us from reading governance material when we actually need a networking specification. We’ve built a rough mental map of where different knowledge domains live, and we update it as the DFINITY Foundation reorganises or expands sections. This upfront orientation pays back enormously.

The Layered Reading Technique We Use at ICPCC

Our team developed what we call the three-pass method after noticing that different documentation sections reward different reading depths. Some pages need only a skim; others demand line-by-line analysis. Trying to read everything at maximum depth was burning us out. The layered approach matches reading intensity to information need, and we’ve been refining it through multiple ICP Community Conference preparation cycles.

Pass one: scanning for the architectural big picture

First pass is strictly about orientation. We scan section headings, diagrams, and introductory paragraphs without stopping to understand every detail. For Internet Computer Protocol docs, this means identifying the major subsystems: consensus, message routing, execution, the NNS. We’re not memorising anything at this stage. We’re building a mental scaffold that later details can attach to. This pass typically takes fifteen to twenty minutes for a new documentation area and leaves us with a rough sketch of how components relate.

Pass two: targeted reading of interface specifications

With the scaffold in place, we return to the sections most relevant to our predefined questions. This is where we read method signatures, candid interfaces, and API references carefully. For DAO-related work, this means studying exactly how the Service Nervous System interfaces expose proposal submission, voting, and treasury management. We take notes on parameters, return types, and error conditions. But we still deliberately skip execution internals and consensus mechanisms unless they’re directly relevant to our immediate task.

Pass three: deep-diving into execution and consensus details

The third pass is reserved for when we need to understand not just what happens but why and how. This is the most cognitively demanding layer and the one we use most sparingly. When we’re designing a feature that interacts with the Network Nervous System at a protocol level, we’ll trace message flows through the entire stack. We read the consensus mechanism specifications, study the state machine replication details, and examine edge cases in the execution environment. This pass can take hours for a single concept, which is precisely why we don’t start here.

Leveraging DAO Governance Documentation for Practical Context

We discovered something interesting after months of working with Internet Computer Protocol materials: the governance documentation often provides the clearest entry point for understanding the protocol as a whole. The Network Nervous System and Service Nervous System docs explain not just governance mechanics but also why the protocol makes certain design choices and how those choices affect real dapps.

Why governance docs accelerate core protocol understanding

The NNS documentation grounds abstract protocol concepts in concrete decision-making processes. When you read about neuron staking, voting power, and proposal execution, you’re simultaneously learning about the protocol’s security model, its economic incentives, and its upgrade mechanisms. We’ve found that developers who start with governance docs develop a more intuitive grasp of why the Internet Computer Protocol works the way it does, rather than just memorising how it works.

Connecting SNS frameworks to practical dapp deployment

The Service Nervous System documentation is particularly valuable because it bridges protocol theory and application development. Reading SNS docs alongside core canister management specifications shows exactly how a DAO on ICP goes from proposal to deployed dapp with its own governance. Our team regularly references SNS documentation when planning ICP Community Conference demonstrations because it maps cleanly to the developer journey from idea to autonomous service.

Building Your Personal Knowledge Graph from Internet Computer Protocol Docs

Reading efficiently is only half the battle. Retaining and connecting what we read required building systems that mirror the interconnected nature of the protocol itself. Our team uses dedicated tools to create personal knowledge graphs that make future reference dramatically faster.

Tools and templates for connected note-taking

We split our team between Obsidian and Notion, depending on preference, but the principles are identical. Every concept gets its own note with bidirectional links to related concepts. A note on “canister cycles” links to “cycle minting,” “resource pricing,” and “NNS cycle management proposals.” Over time, this creates a web of understanding that mirrors the actual protocol architecture. When the DFINITY Foundation releases new documentation, we can immediately see which existing notes might need updating based on the link graph. Our templates include sections for the concept definition, relevant interface specifications, governance implications, and open questions.

How we document gaps and contribute back to the community

No documentation is perfect, and we’ve found that systematically recording gaps improves both our understanding and the broader ecosystem. When we encounter an unclear explanation or missing detail in Internet Computer Protocol docs, we flag it in our knowledge base with a specific note about what was confusing and what we eventually figured out. Several of these notes have turned into community forum posts, documentation contributions, and even topics for ICP Community Conference sessions. The act of documenting gaps forces us to articulate precisely what we don’t understand, which is often the first step toward understanding it.

Staying Updated Without Rereading Everything

The Internet Computer Protocol evolves continuously through NNS-governed upgrades. New features, optimisations, and occasionally breaking changes arrive regularly. We needed a system for tracking what changed without treating every update as a reason to reread the entire documentation corpus.

Monitoring release notes and motion proposals efficiently

We built a lightweight monitoring workflow around the DFINITY Foundation’s release channels and the NNS proposal feed. Rather than reading every proposal, we scan titles and categories for anything touching subsystems we actively work with. Replica version upgrades, new canister features, and changes to the SNS framework all get flagged. The release notes themselves are usually well-structured enough that we can identify which documentation sections are affected and revisit only those. This targeted approach keeps our mental models current without the overhead of full rereads.

Setting up RSS and social listening for the DFINITY Foundation

We maintain an RSS feed from the Internet Computer Protocol developer blog and follow key DFINITY Foundation researchers and engineers on social platforms. Announcements about major documentation overhauls, new technical papers, or upcoming protocol changes often appear in these channels before they hit the main documentation site. This early warning system gives us time to schedule knowledge-graph updates and team discussion sessions around significant changes. It also surfaces community discussions that often clarify documentation ambiguities before official updates land.

Reading protocol documentation efficiently is a learned skill that compounds over time. Every session where we apply these techniques makes the next session easier because our knowledge graph grows denser and our mental models sharpen. Our team is still refining our approach alongside the evolving ICP ecosystem, and we expect that process to continue indefinitely. The Internet Computer Protocol is too ambitious and too active for anyone to master its documentation once and be done. But with deliberate reading strategies, clear objectives, and connected note-taking systems, we’ve turned what used to be a source of dread into one of our team’s genuine competitive advantages.

Frequently Asked Questions

How long does it take to become proficient at reading Internet Computer Protocol documentation?

Our team found that the initial learning curve takes about two to three weeks of consistent, structured reading sessions before the documentation’s organisation feels natural. The key is accepting that you won’t understand everything on first pass and trusting the layered reading method to fill gaps over time.

Do we need to understand cryptography deeply to read ICP protocol docs?

Not for most practical purposes. The Internet Computer Protocol documentation separates high-level concepts from cryptographic implementation details. For dapp development and DAO work through the NNS or SNS, you primarily need to understand what the cryptography achieves rather than how it achieves it. Deep cryptographic study is only necessary if you’re working on core protocol contributions.

Which tool is better for knowledge graphs: Obsidian or Notion?

Both work well, and our team members split roughly evenly between them. Obsidian excels at local-first, fast bidirectional linking with graph visualisation. Notion offers better collaboration features and database functionality. If you work solo, Obsidian’s speed and link graph views are compelling. If your team shares a knowledge base, Notion’s real-time collaboration often wins out.

How often does the DFINITY Foundation update the core protocol documentation?

Major documentation updates typically accompany each replica release, with smaller corrections and improvements appearing continuously. The NNS governance system means protocol changes are publicly proposed and discussed before implementation, giving attentive readers advance notice of what documentation sections will change. We check the release notes with each new replica version for documentation impact.

Can this reading approach work for other blockchain protocol documentation?

Absolutely. We’ve applied variations of the three-pass method and knowledge graph approach to other protocol specifications beyond the Internet Computer. The principles of setting clear objectives, matching reading depth to information need, and building connected notes are universal. The specific documentation structure differs between projects, but the meta-skill of reading technical specifications efficiently transfers well.

ICP vs The Rest: Why We Believe the Internet Computer Protocol Redefines Smart Contracts

We’ll be honest: our team was deeply sceptical of ‘Ethereum killers’ long before we stumbled into the Internet Computer Protocol ecosystem. We’d watched dozens of L1s promise infinite throughput and genuine decentralisation, only to buckle under pressure or quietly reintroduce centralised cloud servers. Hosting the ICP Community Conference changed everything. When we realised we could build an entire interactive conference platform—ticketing, streaming, governance, and the website itself—directly on-chain without touching AWS or a single traditional server, we had to accept that ICP isn’t just another smart contract platform. It’s playing an entirely different game.

The Architecture Graveyard: Why Monolithic Chains Feel Outdated to Us

Traditional Layer 1s rely on vertical scaling—pushing a single chain to its absolute limits. We’ve seen the results. When the London NFT market surged in 2021, Ethereum gas fees briefly exceeded £100 per swap, pricing out casual users and small creators. Solana, marketed as the high-speed saviour, suffered multiple full-day outages that shattered developer confidence. Meanwhile, ICP has maintained 100% uptime since Genesis. The difference lies in chain-key cryptography, which allows the Internet Computer to split into independent subnets that run in parallel, scaling horizontally rather than choking on a single consensus layer.

We remember refreshing Etherscan obsessively, waiting for gwei to drop so we could execute a transaction without burning half our budget. That anxiety simply doesn’t exist on ICP. Canisters operate on a cycles-based model where costs remain predictable. No more gas wars during popular mints, no more failed transactions still draining your wallet. For a team organising a community conference, knowing exactly what infrastructure will cost is non-negotiable. On traditional chains, you’re bidding for limited block space. When demand spikes, you either pay extortionate fees or wait hours. ICP’s subnet architecture allows the network to spawn new subnets as demand grows, effectively creating infinite canister capacity. We’re not competing with DeFi degens for computational resources when we upload conference schedules or process attendee votes. The system expands rather than bottlenecks.

Serving the Web: How ICP Eats HTTP for Breakfast

Most blockchains are brilliant calculators with no mouth. They process transactions brilliantly but can’t serve a webpage to save their lives. ICP smart contracts hold their own memory, compute their own logic, and serve HTML, CSS, JavaScript, and API responses directly to browsers over HTTP. No Infura, no Alchemy, no AWS S3 bucket masquerading as a dapp. This isn’t a minor technical quirk—it fundamentally redefines what ‘on-chain’ means.

Walk through any ‘decentralised’ app ecosystem and you’ll find a dirty secret: the frontend sits on AWS, the metadata lives on IPFS with a centralised pinning service, and the RPC endpoint runs through a single company’s infrastructure. Centralisation creeps back in through the hosting layer. A typical Ethereum dapp relies on at least three centralised cloud providers for basic functionality. That’s not decentralisation; that’s a blockchain backend bolted onto Web2 infrastructure. The ICP Community Conference website is hosted entirely on-chain without AWS or Cloudflare. Every image, every schedule update, every governance proposal—all served directly from canisters to your browser. When you visit icp-cc.com, you’re talking to the blockchain, not a VPS in a London data centre. This matters practically: no hosting bills, no CDN configuration, no certificate renewal, and zero risk of a cloud provider deplatforming our event because someone doesn’t like the agenda.

DAO Dynamics: True Decentralisation or Just Governance Tokens?

We’ve seen the pattern before: a protocol launches a governance token, holders vote on trivial matters using Snapshot, and the core team implements whatever they want regardless. That’s governance theatre, not a DAO. The Internet Computer’s Network Nervous System represents something genuinely different—a fully on-chain governance mechanism that controls protocol upgrades, subnet management, and treasury allocation without off-chain dependencies.

The NNS DAO controls over a billion dollars in ICP value, with higher voting participation rates than typical UK political elections. Neurons—ICP staked for governance—can follow other neurons on specific topics, creating a liquid democracy where you can delegate technical votes to experts while retaining direct control over economic decisions. This isn’t token-weighted plutocracy dressed up as democracy; it’s a sophisticated governance engine that evolves the protocol daily. Our ICPCC planning process utilises a fully on-chain DAO structure. Conference themes, speaker selection, and budget allocations go through genuine community votes executed automatically by canisters. No team member can unilaterally change the website or redirect funds. When the DAO approves a proposal, the canister updates itself. This level of autonomous governance would be impossible on chains where ‘DAO’ means a multisig wallet and a Discord poll.

The Developer Experience: Canisters, Actors, and the Motoko Surprise

Solidity taught an entire generation to think of smart contracts as single-threaded, sequential state machines. ICP introduces the actor model, where canisters operate concurrently, communicating through asynchronous messaging. For developers coming from distributed systems backgrounds, this feels natural. For those steeped in EVM patterns, it requires a mental shift—but one that unlocks genuine composability without worrying about reentrancy attacks or gas limits aborting complex operations mid-flight.

ICP flips the traditional transaction model on its head. Developers fund canisters with cycles, and users interact without paying gas fees, holding tokens, or even knowing they’re using a blockchain. For UK fintech applications, this is revolutionary. Imagine a payments dapp where customers simply use the service—no wallet setup, no ETH purchase, no gas fee surprises. Onboarding friction drops to near-zero, which is precisely what London’s financial innovation sandbox demands. We’ve spent countless hours debating whether Motoko or Rust represents the better choice for canister development. Motoko offers native actor-model syntax and seamless ICP integration, making it approachable for developers tired of Solidity’s limitations. Rust provides raw performance and a massive ecosystem. Our team splits roughly down the middle, with Motoko favoured for rapid prototyping and Rust for performance-critical canisters. Having this choice rather than being locked into a single language speaks volumes about the platform’s maturity.

The Multi-Chain Reality: Coexistence or Cannibalization?

We’re not tribal maximalists. Bitcoin remains the foundational store of value, and Ethereum’s DeFi ecosystem isn’t disappearing overnight. What excites us is how ICP positions itself as a unifying layer rather than a competitor. Through Chain Fusion technology, canisters can directly sign Bitcoin transactions, hold BTC, and interact with the Bitcoin network without bridges, wrappers, or intermediaries.

ckBTC allows native Bitcoin transactions with finality speeds suitable for London’s fintech sandbox testing. Unlike wrapped BTC on Ethereum, which introduces custodial risk and bridge vulnerabilities, ckBTC is minted and redeemed through direct ICP-Bitcoin integration. Canisters hold real Bitcoin addresses and sign real transactions. For the first time, Bitcoin gains programmability without sacrificing sovereignty—a proposition that’s captured serious attention in the City of London. We’ve observed growing interest from London’s financial district in this synthesis of traditional value and programmable logic. The ability to build applications that interact natively with Bitcoin while offering web-speed user experiences opens doors for compliant, institutional-grade DeFi. When a canister can custody BTC, serve a web interface, and execute governance decisions autonomously, the technology stack aligns with how regulated financial institutions actually want to operate.

Conclusion

We remain platform agnostic at heart—our loyalty is to whatever technology best serves the community. But the practical requirements of running a large-scale event like the ICP Community Conference have proven something undeniable: ICP is currently the only protocol delivering a truly sovereign, end-to-end on-chain experience without cutting corners. From the website to the treasury to the governance votes, every component lives on-chain. No cloud providers. No centralised fallbacks. No compromises. That’s not just a technical achievement; it’s a statement about what decentralisation should mean.

FAQ

• What makes the Internet Computer Protocol different from Ethereum? ICP scales horizontally through independent subnets rather than relying on a single chain. It serves web content directly from smart contracts without cloud providers, uses a reverse gas model where developers fund operations instead of users paying per transaction, and integrates natively with Bitcoin through Chain Fusion technology without bridges.
• Is the ICP Community Conference website really hosted entirely on-chain? Yes. The ICPCC website runs completely on-chain without AWS, Cloudflare, or any centralised hosting service. Every page, image, and interaction is served directly from canisters to your browser over HTTP, demonstrating that ICP smart contracts can function as complete web servers.
• How does ICP’s reverse gas model benefit UK fintech applications? The reverse gas model eliminates user-facing transaction fees, token requirements, and wallet setup. For fintech applications targeting mainstream UK consumers, this means users can interact with blockchain-powered services as easily as they use traditional banking apps—no crypto knowledge required, no gas fee surprises during transactions.
• What is ckBTC and why does it matter for Bitcoin integration? ckBTC is a token that represents Bitcoin held directly by ICP canisters through native Chain Fusion integration. Unlike wrapped Bitcoin on other chains, ckBTC requires no bridges or third-party custodians. Canisters can sign Bitcoin transactions and hold real BTC addresses, enabling Bitcoin programmability with settlement finality suitable for institutional use.
• How does the NNS DAO compare to governance systems on other blockchains? The Network Nervous System operates fully on-chain with liquid democracy features, automatic execution of approved proposals, and direct control over protocol upgrades and treasury funds exceeding a billion dollars in value. Unlike off-chain voting tools commonly used elsewhere, NNS decisions are binding and implemented autonomously without team intervention.

The ICPCC Talks Our Team Keeps Rewatching

We’ve all been there. You watch a brilliant conference talk, the live chat goes wild, you bookmark it for later, and then the Slack notifications swallow it whole. Most conference content has a half-life of about 48 hours. But after the latest ICP Community Conference, something different happened. Our team kept returning to the recordings—not out of obligation, but because certain sessions genuinely changed how we build on the Internet Computer Protocol. We’d find ourselves quoting specific slides in sprint planning, or pausing a fireside chat to argue about composability. These aren’t just archived streams gathering digital dust; they’re the sessions that rewired our approach to DAO governance, scalability, and on-chain identity. Here are the talks we haven’t stopped rewatching, and why they matter for anyone building in the UK ecosystem right now.

The DAO Governance Deep Dive That Shifted Our Thinking

We thought we understood DAO governance until we watched the deep dive on the Service Nervous System (SNS). This wasn’t another theoretical walkthrough of voting mechanisms. The team from the DFINITY Foundation broke down liquid democracy with such clarity that even our front-end developers, who normally avoid governance debates, leaned in. They walked through how neurons track voting history, how you can delegate specific decision types while keeping veto power on others, and what happens when a proposal hits a contentious threshold. The live demo of a DAO tooling dashboard—showing real-time proposal lifecycles for an active SNS—made the whole thing feel tangible, not aspirational.

Why on-chain voting finally feels practical

The friction with on-chain voting has always been the cognitive load. Nobody wants to evaluate thirty technical proposals a week. This session showed how followees can be tagged by expertise category, so you might delegate treasury management votes to a finance-focused neuron holder while keeping product roadmap votes under your direct control. They demoed a UI that surfaces your delegate’s voting record and flags when they deviate from their stated principles. That accountability layer is what we’ve been missing. It transforms delegation from blind trust into an informed, revocable choice. One of our engineers immediately started sketching a similar dashboard for our own SNS setup.

The one slide on neuron staking we screenshotted

There was a single slide—slide 17, we checked—that mapped out dissolve delay bonuses against voting power curves in a way that finally made the incentive structure click. It visualised how an eight-year dissolve delay compares to a six-month one, not just in raw multiplier terms but in effective influence over proposal outcomes. That screenshot lives in our team’s Notion now. Whenever someone questions why we recommend longer staking periods for core contributors, we drop the image. It’s become shorthand for a whole conversation about long-term alignment in DAOs.

Internet Computer Protocol Infrastructure: The Scaling Keynote

The technical keynote on subnet architecture was dense, but in the best way. The speakers tackled the questions European node operators have been raising for months—particularly around latency and geographic distribution. For UK-based developers and node providers, the discussion on boundary node architecture felt overdue. They addressed how requests route through boundary nodes before hitting subnet replicas, and what that means for users in London versus Singapore. The transparency about current limitations was refreshing; they didn’t pretend every metric was perfect, and that honesty made the roadmap more credible.

Breaking down the boundary node improvements

Boundary nodes act as the entry point to the Internet Computer, handling TLS termination and routing requests to the correct subnet. The keynote detailed recent improvements to the boundary node layer that reduce latency by caching routing tables more aggressively and pre-establishing connections to frequently accessed canisters. For a user in Manchester hitting a dApp deployed on a European subnet, these changes shave off milliseconds that compound across API calls. The team showed benchmarks comparing response times before and after the update, and the difference was significant enough that we immediately checked whether our own canisters were benefiting.

What the new scalability figures mean for UK developers

The keynote included updated throughput numbers that sparked a flurry of messages in our team channel. Subnets can now handle more canisters and higher transaction volumes than the figures quoted at previous conferences. For UK startups building consumer-facing applications, this changes the calculus. You’re no longer worrying about whether your canister will hit a ceiling if your user base doubles. The presenters mapped out a trajectory that suggests subnets will scale further without requiring developers to restructure their code. That stability promise matters when you’re pitching on-chain architecture to a board that remembers the gas fee spikes of other networks.

Real-World Web3: The London Use-Case Panel

This panel was the standout for sheer practicality. Three London-based on-chain startup founders sat on stage and talked honestly about what worked, what broke, and what cost less than they expected. No hype, no token talk—just operational reality. One founder described migrating their entire backend from AWS to canister smart contracts over a single weekend, then spending the following week fixing assumptions they’d carried over from Web2 architecture. The room was packed, and the Q&A ran over by twenty minutes because the audience kept asking specific questions about gas costs, uptime guarantees, and user onboarding flows.

From traditional cloud to 100% on-chain in Soho

One founder, running a fintech compliance tool out of a Soho coworking space, detailed their migration path. They’d been spending roughly £4,200 monthly on cloud infrastructure for a product that processed regulatory checks. After moving fully on-chain, their infrastructure costs dropped to the cost of cycles—less than £300 per month. The trade-off was rethinking their database architecture entirely. Instead of a PostgreSQL instance, they used stable memory in a canister. Instead of a message queue, they used inter-canister calls. The founder admitted the mental shift was harder than the technical one, but the numbers spoke for themselves.

The regulatory clarity discussion everyone applauded

Midway through the panel, the conversation turned to the UK’s regulatory environment for blockchain-based businesses. One panellist, who had recently completed a sandbox programme with the FCA, explained how running fully on-chain actually simplified their compliance reporting. Because every transaction is auditable and the canister code is verifiable, they could demonstrate data integrity without building a separate audit trail. The audience reaction was telling—a round of applause broke out when the founder said regulators weren’t the obstacle; opaque off-chain systems were. That moment crystallised something we’d been feeling but hadn’t articulated.

The Decentralized Identity Talk We Didn’t Expect to Love

Identity sessions tend to be dry. This one wasn’t. The Internet Identity presentation opened with a live biometric authentication demo—FaceID on a volunteer’s phone, generating a session key that authenticated against a canister on stage. It worked first time, which anyone who’s done live demos knows is half miracle. But the real energy came from what followed: a discussion about applying this technology to public services, specifically the NHS. The room split into camps, and the Q&A became a proper debate rather than polite questions.

How passkeys beat passwords in a live stress test

The demo wasn’t just a happy path walkthrough. The presenter deliberately used a device they’d never authenticated with before, showing how passkeys eliminate the need to remember or store credentials. They registered a new anchor, signed a transaction, and then revoked the session—all in under thirty seconds. Compared to the average password reset flow, which studies show takes over three minutes and often leads to abandonment, the efficiency gain is staggering. For UK services trying to reduce drop-off during onboarding, this matters.

The audience debate on NHS and citizen data

Things got heated when an audience member asked whether Internet Identity could underpin NHS patient records. Privacy advocates in the room raised concerns about biometric data centralisation, while others pointed out that the architecture doesn’t store biometrics on-chain—the authentication happens locally, and only a derived public key touches the network. A GP from Birmingham stood up and described the current nightmare of cross-trust record sharing, and suddenly the conversation wasn’t theoretical anymore. We left that session convinced that decentralised identity for public services is closer than most people think, and that the UK might be the proving ground.

Our Favorite Fireside Chat: Building Open Internet Services

Sometimes the unscripted sessions deliver the most value. This fireside chat paired two core ICP engineers with three community developers, and the result was a candid, occasionally blunt conversation about why the industry keeps defaulting to centralised clouds. The DFINITY Foundation roadmap came up repeatedly, not as a sales pitch but as a reference point for what’s realistically achievable in the next twelve months. The tone was relaxed but the ideas were sharp—the kind of discussion that makes you rethink assumptions you didn’t know you held.

The moment the conversation turned to true composability

One engineer described building a lending protocol that called into a separate identity canister and a separate reputation canister, neither of which their team had written. On traditional infrastructure, this would require API keys, rate limiting negotiations, and trust assumptions. On the Internet Computer, it required knowing the canister IDs. The community developer who’d built the reputation system was sitting in the audience and confirmed they had no idea their canister was being used that way. That’s real composability—not just theoretical interoperability but actual, unplanned reuse. Our team has since adopted this as a design principle: build canisters that other developers might call without asking permission.

Why we keep quoting the ‘serverless is a myth’ remark

Halfway through, one of the DFINITY engineers said, “Serverless is a myth—there’s always a server, you just don’t own it.” The line landed hard. The point wasn’t that serverless functions are useless, but that they obscure the centralisation underneath. When you deploy to a cloud function, you’re running on Amazon’s or Google’s servers, subject to their pricing changes and usage policies. On the Internet Computer, the servers belong to a decentralised network of independent node providers. We’ve quoted that remark in three client meetings since, and it consistently reframes the conversation from cost comparison to sovereignty.

The Community Lightning Sessions That Deserve a Full Rewatch

The lightning session format—seven minutes per project, no exceptions—forced presenters to cut the fluff. What emerged was a showcase of raw experimentation from independent builders who’d been tinkering with canister smart contracts in ways the core protocol designers probably never anticipated. The Manchester and Bristol developer communities were particularly well-represented, reflecting the growing concentration of ICP talent outside London.

The micropayment dApp that surprised everyone

A developer from Manchester demonstrated a micropayment system for pay-per-article journalism, built entirely in a single canister. The twist: transaction amounts as low as £0.01 were economically viable because the Internet Computer’s reverse gas model means users don’t pay per transaction. The audience audibly reacted when the presenter showed a live payment of half a penny clearing instantly. Traditional payment rails would lose money on that transaction; here, it just worked. Six months later, that dApp has processed over a hundred thousand micropayments, and the developer is in talks with a regional newspaper group.

A zero-knowledge proof experiment born in a UK hackathon

A team from Bristol presented a zero-knowledge proof implementation they’d built during a weekend hackathon. It wasn’t production-ready—they were upfront about that—but the fact that they could run ZKP verification inside a canister at all was remarkable. They used the example of proving age without revealing a birthdate, a use case directly relevant to the UK’s evolving digital identity standards. The project has since received a grant and is evolving into a privacy layer that other canisters can call. Watching that lightning talk now feels like seeing an early draft of something significant.

FAQ

What is the ICP Community Conference?

The ICP Community Conference (ICPCC) is a global event focused on the Internet Computer Protocol, bringing together developers, founders, and researchers to share technical insights, project demos, and governance discussions. It features keynotes from the DFINITY Foundation alongside independent community talks and panels.

How does the Service Nervous System (SNS) work?

The Service Nervous System is an on-chain governance framework that allows DAOs to control canister smart contracts through proposal-based voting. Token holders stake neurons with configurable dissolve delays and can vote directly or delegate voting power to trusted followees, creating a liquid democracy system.

Can UK startups realistically build fully on-chain?

Yes, and several London-based founders demonstrated this during the conference. The Internet Computer’s canister architecture can replace traditional cloud infrastructure for many use cases, with significant cost reductions reported. The main challenge is architectural rethinking rather than technical limitation.

Is Internet Identity safe for sensitive data like NHS records?

Internet Identity uses passkeys and biometric authentication that processes credentials locally on a user’s device. No biometric data is stored on-chain—only a derived public key. The architecture is designed to be privacy-preserving, though implementation for public services would require additional governance and compliance layers.

Where can I watch these ICPCC talks?

All sessions from the ICP Community Conference are available on the official ICP YouTube channel and through the conference archive. We recommend starting with the governance deep dive and the lightning sessions if you want to see the breadth of what’s being built on the Internet Computer Protocol.

How We Fund the Future: A Guide to ICP Community Grants and Applications

I still remember standing in a tucked-away corner of a London pub during our first ICP Community Conference side event, watching a developer scribble the bones of a decentralised social feed on a napkin. He had no pitch deck, no polished tokenomics—just a working demo on his phone and an idea that refused to leave him alone. A few months later, a tiny grant from the ICPCC DAO turned that napkin sketch into a live dApp. It wasn’t the size of the cheque that made the difference; it was the signal. That moment cemented what we already believed: community funding isn’t a charity gesture, it’s the beating heart of the Internet Computer Protocol ecosystem, and it’s how we build things that actually last.

Why Our Community Runs on Grants, Not Just Code

Plenty of blockchains run on code. We run on something harder to replicate: a conviction that the people closest to a problem should decide where the treasury flows. Our grants programme doesn’t just fill a gap—it replaces the gatekeepers. Instead of a handful of partners deciding what gets built, the ICPCC DAO puts allocation power into the hands of the builders, stakers, and believers who show up every day.

The DAO Treasury: More Than a Prize Pool

When you hear “DAO treasury,” it’s easy to imagine a static prize pool that gets dipped into once a year for a hackathon. That’s not how we operate. The ICPCC DAO treasury is a living, community-governed resource that funds everything from initial prototypes to full-scale dApps, with every significant allocation shaped by the Service Nervous System (SNS). This means token holders vote directly on grant proposals, so a project backed by a handful of London developers can earn just as much weight as one that comes wrapped in Silicon Valley polish. The treasury isn’t a wealthy patron; it’s a collective heartbeat that rewards genuine traction over pedigree.

Breaking the London VC Bottleneck

UK builders know the London VC scene well—it’s high-quality money, but it often demands a level of polish, warm introductions, and revenue projections that can strangle early-stage Web3 experimentation. Community grants smash that bottleneck. We’ve seen developers fresh out of London blockchain meetups secure their first meaningful funding because they shipped a rough-but-functional MVP that resonated with the ICP community. Distrikt, the decentralised social media platform that carries strong UK community ties, is a perfect example. It didn’t start with a glossy raise. It grew out of a conviction that on-chain social belonged to users, not corporations—and grants helped it catch fire. That path is open to anyone willing to build in the open.

What We Actually Look For in an Application

Let’s be brutally honest: we’ve seen applications that read like sci-fi novels and applications that are two paragraphs long with a GitHub link. We’ll take the GitHub link every time. The selection criteria aren’t a mystery, but they aren’t what you’ll find in a traditional accelerator, either.

The ‘Shipping Code’ Factor vs. The Hype Pitch

Our reviewers aren’t impressed by jargon-heavy whitepapers. We want evidence that you’ve built something tangible—even if it’s janky. A working MVP, a public repo with real commits, and a clear explanation of what the grant unlocks matter infinitely more than a 20-slide deck. Tell us what you’ve actually shipped, what broke along the way, and why the next milestone requires community funding. If we can see that you understand your users—even if that’s a handful of testers from a London ICP meetup—you’re already ahead of most.

Technical Integration: Why ckBTC and HTTP Outcalls Matter

Right now, two technical capabilities sit at the top of our priority list. The first is ckBTC—chain-key Bitcoin—which gives ICP smart contracts direct, trustless access to native Bitcoin. A grant application that shows how you’ll integrate ckBTC for payments, collateral, or cross-chain logic instantly signals that you’re building with the full power of the protocol, not just hovering on the surface. The second is HTTP Outcalls, the feature that lets canisters fetch data directly from Web2 APIs without oracles. Whether you’re pulling live sports scores or verifying off-chain identity, these integrations demonstrate that you know why ICP is architecturally different. We’re not looking for buzzwords—we’re looking for builders who understand that ckBTC and HTTP Outcalls turn the Internet Computer into a true Web3 engine, and who are ready to prove it.

The Anatomy of a Winning Proposal

The application form itself isn’t designed to trip you up, but it does demand clarity. A winning proposal walks us through the problem, the solution, and—most critically—a milestone plan we can actually verify. Here’s what a solid application always includes:

• A crisp problem statement that shows you understand the user, not just the technology.
• A link to a live demo or a public repository (even an early prototype counts).
• A milestone table with concrete deliverables, not vague “research and development” lines.
• A transparent budget that accounts for how you’ll handle the conversion from ICP to GBP or stablecoins.
• A brief note on your team—no need for CVs, just enough to show you can ship.

Milestone Planning: Be Brutally Realistic

Almost every application we’ve had to reject tripped over the same hurdle: overpromising on timelines. We’d rather fund three achievable milestones in six months than ten imagined ones in the same window. Break your roadmap into chunks where each milestone ends with a shippable artefact—a testnet deploy, a UI walkthrough, a closed beta with five real users. Keep it small, keep it honest, and keep it verifiable. The community, through the SNS vote, will reward that discipline.

Managing Volatility: ICP to GBP Budgeting

Grants are typically paid in ICP, but we know UK builders think in pounds sterling when planning rent, tools, and contributor stipends. A strong proposal explains how you’ll manage that volatility during the build phase. Many teams use a straightforward approach: convert a portion of the grant into stablecoins or GBP upon receipt to lock in the core budget, and hold a smaller amount in ICP for longer-term upside. This kind of practical financial thinking tells us you’re serious about delivering—and it aligns with the UK financial planning norms that keep projects grounded.

Navigating the ICPCC Review and KYC Process

From submission to decision, we’ve optimised the process so that governance doesn’t become gridlock. You submit, we review, and then the wider community participates in the final call—all with a level of compliance that satisfies UK expectations without burying you in paperwork.

From Submission to the SNS Vote

After your application lands, our grants committee performs an initial quality check, and eligible proposals move forward to the community discussion phase. Within days, the proposal goes live on the SNS, where token holders cast their votes. This isn’t a rubber stamp—people ask hard questions in the forum, and you should be ready to answer them. A typical turnaround from final submission to decision sits around two to three weeks, often faster when the vote signal is clear. The SNS vote isn’t just a formality; it’s the mechanism that keeps the treasury accountable to the people who fuel it.

UK Compliance Without the Headache

Because the ICPCC operates as a UK-facing entity, we’ve built a compliance layer that’s strict but swift. KYC checks are required before funds move, but we’ve stripped away the unnecessary friction. You’ll provide basic identity verification, confirm wallet ownership, and sign a simple grant agreement that lays out milestones and reporting expectations. The entire process is designed to feel less like a bank interrogation and more like a sensible gate that protects both the DAO and the builders.

Our Team’s Top Tips for Post-Grant Success

Getting the ICP into your wallet is just the first frame of the reel. What comes next determines whether your project becomes a community staple or a forgotten commit history.

Reporting Back to the DAO

We don’t ask for weekly slide decks, but we do expect honest, public check-ins at each milestone. A short update in the community forum—what you built, what broke, how you spent the funds—keeps trust intact and makes it far easier to secure follow-up grants later. Think of it as building your reputation on-chain. Teams that communicate transparently tend to find the community rallying around them when they hit a rough patch.

Scaling Up: From Grant to Global dApp

Several of our most successful grantees used the initial funding to hit a single milestone, then leveraged the ICPCC network to go further. We’ve hosted mainnet launch parties in London that turned local demos into global attention, and we actively connect builders with mentors, liquidity partners, and later-stage funding sources. If you ship what you promised and show real user adoption, reapplying for follow-up grants isn’t just possible—it’s encouraged. The DAO wants to back winners, and nothing proves commitment like delivered code.

Applying for an ICPCC community grant isn’t just a financial transaction. It’s an invitation to join a tightly-knit, opinionated family of builders who are putting the UK on the map for Web3 innovation. We celebrate the messy prototypes, the honest failures, and the commits that ship at 2 a.m. because we know that’s where lasting infrastructure is born. If you’re ready to build in the open and let the community have your back, we’re ready to read your application.

FAQ

Who can apply for an ICPCC community grant?

Any individual or team building on the Internet Computer Protocol can apply. We don’t require a registered company, and we’ve funded everyone from solo developers at London meetups to established project teams. The only firm requirements are a demonstrable connection to the ICP ecosystem and a willingness to go through standard KYC checks as a UK-facing initiative.

Do I need a fully built dApp to qualify?

No. We actively fund projects at the prototype and MVP stage. A live demo or a public repository with working functionality carries significantly more weight than a polished whitepaper. If you can show that you’ve already begun solving the problem and just need fuel to reach the next milestone, you’re exactly the type of applicant we want.

How does the SNS voting process affect my application?

Once the grants committee clears your proposal, it moves to the SNS for a community vote. ICPCC token holders review the application, ask questions in the forum, and cast their votes. A strong, transparent proposal with realistic milestones tends to attract positive attention quickly. The vote ensures that the DAO treasury is allocated by the community, not behind closed doors.

Can I receive the grant directly in GBP?

Grants are disbursed in ICP, but we expect you to budget in GBP and outline how you’ll manage volatility—for example, by converting a portion into stablecoins or fiat upon receipt. This approach keeps your runway predictable and aligns with common UK financial planning practices.

What reporting is required after receiving a grant?

We ask for milestone-based public updates in the community forum, not invasive weekly reports. Each update should cover what you delivered, how funds were used, and any pivots or challenges. Honest, timely communication not only satisfies the grant agreement but also builds the on-chain reputation that makes follow-up funding much easier to secure.