Standard Scripts vs Non-Standard Scripts: The Easily Overlooked Boundary in BSV Development

In BSV development, there is an easily overlooked boundary: a transaction being "theoretically valid" and "the network will actually process it" are not the same thing.

In a Nutshell

• Standard scripts: More readily accepted by miners and services.
• Non-standard scripts: May be valid under consensus, but might not be relayed, accepted, or mined.

Consensus Rules vs Policy Rules

First, distinguish between two types of rules:

• Consensus rules: Determine whether a transaction is valid once included in a block. Violating these rules leads to the block being rejected by the network.
• Policy rules (Miner Policy): Determine whether a node or miner is willing to relay, accept, and mine a given transaction.

In short:

• Consensus rules: What is absolutely invalid.
• Policy rules: Whether I am willing to process it.

A script may not violate consensus rules, but if it does not conform to miner policies, the transaction may still struggle to be broadcast or confirmed.

What Are Standard Scripts

Standard scripts are common script patterns widely accepted by wallets and miners in the ecosystem, for example:

• P2PKH ordinary payments
• Regular OP_RETURN data outputs
• Broadly supported script templates

Benefits of standard scripts include:

• Easily generated by wallets
• Easily parsed by services
• More likely to be accepted by miners
• More debugging resources available
• Clearer display in block explorers

Newcomers and production applications should prioritize standard scripts or well-established protocols.

What Are Non-Standard Scripts

Non-standard scripts may include:

• Rare opcode combinations
• Oversized scripts
• Scripts that do not conform to current miner policy
• Custom protocols unrecognized by wallets and services
• Transaction structures that exceed certain service limits

Non-standard does not necessarily mean consensus-invalid. Such transactions might theoretically be acceptable in a block, but in practice they may:

• Not be mined by any miner
• Be directly rejected by intermediary services

Why This Matters for BSV

BSV emphasizes Script capability and on-chain application protocols, giving developers great freedom but also introducing risks. You might write a script that passes local testing but fails when broadcast. The reason may not be cryptographic errors but rather:

• Script too large
• Transaction too large
• Fee rate not meeting policy
• Output too small
• Service does not support that script type
• Miner does not accept that transaction pattern

This is why when developing BSV applications, you cannot rely solely on local test results; you must also consider current network and miner policies.

Standardity and SDK

Using an SDK can reduce many errors, but an SDK cannot guarantee that your business script will be accepted by the network. An SDK can help you:

• Construct transactions
• Serialize
• Sign
• Generate common scripts

However, if you create custom scripts or large data transactions, you must still confirm:

• Whether the current miner accepts them
• Whether ARC or broadcast services accept them
• Whether the fee is sufficient
• Whether outputs comply with policy
• Whether script size and transaction size are reasonable

Standardity and Application Protocols

Application protocols do not have to be entirely embedded in Script. Sometimes it is more reasonable to:

• Keep on-chain scripts simple
• Use OP_RETURN or outputs to record data
• Have business rules validated by Overlay
• Use signatures for critical authorization
• Place complex queries in the application indexing layer

This approach reduces on-chain script complexity while maintaining verifiability. BSV's tech stack is not "cram all logic into Script"; rather, it relies on Script, transaction formats, SPV, Overlay, and the application layer working together.

How to Reduce Non-Standard Risk

In practice, you can do the following:

• Prioritize official SDKs and mature templates
• Test in small-value environments first
• Read miner or transaction processor documentation
• Use services like ARC to observe error responses
• Control transaction size and script size
• Add version numbers to data protocols
• Avoid unnecessarily complex scripts
• Log raw transactions and error messages

Production applications should treat broadcast failures as a normal occurrence, rather than assuming all transactions will be accepted.

Common Misconceptions for Beginners

• Non-standard does not necessarily mean consensus-invalid.
• Local script verification passing does not guarantee network acceptance.
• Standardity can be affected by miner policies and service policies.
• Complex scripts are not necessarily better than simple ones.
• SDKs cannot replace understanding of miner policies.
• Application-level rules can be validated via Overlay; they need not all be written into Script.

References

• Script docs
• ARC GitHub
• Advanced Transaction Construction