Smart contract development, protocol engineering, and cryptographic research qualify under IRC Section 41. Protocol teams, DeFi developers, Web3 infrastructure companies, and enterprise blockchain engineers qualify right now.
Most blockchain and Web3 companies that qualify do not think of their engineering work as research. But if your protocol team is designing a novel consensus mechanism, your smart contract developers are building a new AMM curve, your infrastructure engineers are developing a zero-knowledge proving system, or your tokenization team is solving on-chain compliance logic where the technical outcome is uncertain at the start, the R&D credit likely applies right now.
The R&D credit covers qualifying engineering and technical development activity. Issuing tokens, raising capital, marketing, community management, and standard business operations do not affect R&D credit eligibility for the underlying engineering work. A DeFi protocol can claim the credit on the engineering team that designed the AMM curve and the formal verification of the smart contract system, regardless of token structure or treasury activity. The protocol engineering and the business operations are evaluated separately. Many Web3 companies leave the credit unclaimed simply because no one connected their engineering work to an IRC Section 41 analysis.
The work must aim to develop or improve the functionality, performance, reliability, or quality of a process, technique, formula, or software component. Blockchain and Web3 companies meet this test through developing faster consensus finality, more efficient smart contract execution, more reliable oracle integration, lower-latency cross-chain bridging, or more robust cryptographic verification systems. Experimental failure counts. Failed consensus designs, rejected AMM curve configurations, and proof systems that did not meet performance thresholds all contribute qualifying research expenses.
A Layer 2 protocol team designs a novel rollup architecture targeting sub-second finality for a specific transaction class. The first proving system design fails to meet gas cost thresholds on mainnet. A second approach using a different ZK circuit construction meets performance targets after three iterations. All iterations qualify because the intent throughout was to improve transaction finality and reduce execution cost under engineering uncertainty.
This prong is met by any Web3 team developing a technically better protocol, contract, or infrastructure component. Protocol engineers, cryptographers, smart contract developers, and distributed systems engineers all perform work that satisfies this test as part of their standard scope.
The work must rely on principles of computer science, mathematics, engineering, or physical science. Blockchain and Web3 engineering is inherently grounded in these disciplines: cryptography, distributed systems theory, formal verification, game theory, and software engineering all satisfy this prong. Business decisions about tokenomics, governance structures, market positioning, and community incentive design do not qualify, but the engineering underlying the protocol mechanics does.
A DeFi team develops a novel liquidity concentration mechanism drawing on mathematical optimization, game theory equilibrium analysis, and Solidity engineering. An enterprise blockchain team designs a permissioned ledger identity system using cryptographic commitment schemes and zero-knowledge credential proofs. Both draw on recognized scientific and mathematical foundations and satisfy the technological prong directly.
The threshold is low for blockchain protocol and smart contract engineering because the scientific foundation is inherent to the discipline. Cryptography, distributed systems, formal methods, and algorithm design all rest on established computer science principles.
The work must aim to eliminate uncertainty about the capability or method of achieving a technical result. Blockchain development is dense with this kind of uncertainty: whether a new consensus mechanism will reach finality within a latency target, whether a ZK circuit design will fit within gas limits, whether a novel AMM formula will remain solvent across extreme market conditions, or whether a cross-chain bridge architecture can meet security guarantees.
A Web3 infrastructure company develops a novel RPC aggregation layer and does not know at the start whether their caching and routing architecture can achieve sub-10ms response times under mainnet load. The engineering team runs systematic load tests, adjusts the aggregation logic through multiple iterations, and validates performance against the defined latency requirement. The uncertainty about the technical method is eliminated through the experimental process.
Blockchain engineering frequently involves uncertainty about both capability (can this be done at all) and method (which approach will achieve the performance target). Either form of uncertainty qualifies.
The work must involve a process of evaluating alternatives to eliminate technical uncertainty. This does not require a formal lab or a dedicated research team. In blockchain and Web3 development, the experimental process is typically the engineering workflow itself: designing candidate approaches, running testnets and simulations, evaluating performance against defined criteria, and iterating on the architecture or algorithm. Contemporaneous documentation of this process is the foundation of a defensible R&D credit study.
An OFS company tests three different sensor configurations in a controlled wellbore environment before commercializing a new downhole logging tool. Each configuration is evaluated against defined performance criteria. Results are documented and compared. The systematic evaluation of alternatives is the process of experimentation. The documentation of that process is what makes the credit defensible under examination.
Testnet deployments, simulation runs, security audits against defined performance criteria, and comparative protocol benchmarking all constitute experimental processes under IRC Section 41.
For the full four-part test explanation with examples across industries, see the main R&D Tax Credit page.
Each sub-sector below includes the qualifying activities, the typical expense breakdown, and the primary exclusion. Select your company type.
A 22-person Layer 2 protocol team building an EVM-compatible rollup identified a gap during testnet validation: their existing optimistic fraud proof construction was producing finality latencies outside the envelope their integrating dApps required for production traffic. The protocol engineering team spent 11 months evaluating four alternative proof system architectures (a multi-stage interactive fraud proof variant, two validity proof constructions, and a hybrid attestation model) across a defined benchmark suite of 30 representative transaction patterns drawn from mainnet traces. They built three working implementations and ran adversarial tests on each before finalizing the design.
The work grew naturally from product engineering, not labeled research. Architecture decision records, the benchmark logs across the 30 transaction patterns, and the rejected proof system implementations all formed contemporaneous proof of experimentation. The team described the project as "rebuilding the proof system." aecre's technical interview process identified the qualifying experimental structure within that description and built the proof of experimentation documentation around it.
A 14-person DeFi protocol team building a derivatives platform on Ethereum identified a structural problem: the standard constant-product AMM formula produced slippage characteristics that made the protocol uncompetitive for the asset pairs they targeted. The team spent nine months designing a novel custom invariant function, evaluating five alternative curve formulations and two hybrid approaches across a defined simulation cohort of 12 historical market scenarios spanning volatile and trending periods. The team coordinated formal verification of the final invariant with an outside cryptography firm and ran adversarial stress tests on the contract suite before mainnet deployment.
The team had no internal R&D classification for the work. They considered it "designing the AMM." But the documented technical uncertainty about whether the custom curve would maintain solvency invariants under adversarial conditions, the systematic evaluation of alternative curve constructions against the 12-scenario simulation cohort, and the formal verification engagement all met the criteria for qualifying research expenses under IRC Section 41.
An eight-person ZK infrastructure startup building privacy primitives for an institutional use case identified a barrier: their existing ZK-SNARK circuit construction produced proving costs that priced the service out of the target market. The cryptographic engineering team spent 13 months developing a novel recursive proof composition approach, evaluating three alternative proof systems (a Plonk-derived custom circuit, a STARK construction, and a folding scheme) and four constraint system designs against a defined benchmark of seven production-representative computations. They built working circuit implementations of each and measured proving time, verification time, and proof size across the benchmark.
The team described the work in cryptography terms (circuit optimization, recursion, commitment schemes) and never connected it to research and development tax framing. aecre's technical interview process identified the qualifying experimental structure across the 13-month program and built the documentation file around the existing engineering artifacts: circuit implementations, benchmark logs, and the cryptographic engineering memoranda the team had already produced.
A 16-person cross-chain infrastructure team identified a structural problem with their existing bridge architecture: the trusted-validator pattern they had inherited from open-source reference implementations created an attack surface incompatible with the security guarantees their integrating chains required. Their protocol engineering team spent 10 months designing a novel light-client based message verification scheme, evaluating four alternative verification architectures (an optimistic fraud proof variant, a ZK light client construction, a Merkle accumulator design, and a hybrid attestation model) across a defined adversarial test cohort of 18 attack scenarios. They built working implementations of two of the four candidates and ran adversarial simulations on each.
The work was performed under contract pressure. The team's integrating partners required a security upgrade and the engineering window was tight. The team described the work as "rebuilding the verification layer" and never framed it as research. Architecture decision records, the rejected verification architecture implementations, the adversarial simulation logs, and the cryptographic engineering memoranda all formed contemporaneous proof of experimentation that aecre identified during the technical interview without asking the team to reconstruct the work.
Answer the quick check questions to see if your company qualifies.
Most blockchain and Web3 pass-through entities (S-Corps, partnerships, LLCs) see the full credit benefit at individual rates. Nearly 40 states stack additional credits on top of the federal credit. The federal number is the floor.
The feasibility conversation takes 30 minutes. We assess your qualifying activities, estimate credit value, and tell you plainly whether a study makes sense for your company. No commitment, no cost.
Book a Free AssessmentWe respond within one business day. Partner-led from first conversation through filing.