This specification describes how to secure transaction creation, transport, signing and deployment, to reduce as far as possible risks that malicious parties or operational errors cause unanticipated loss or theft.
Supply chain hacks, front-running, crypto-clippers, malicious software, and operational errors have all been a cause of transactions being carried out that do not represent what was intended, leading to substantial losses and to far larger risk exposure - although fortunately some errors whose potential risk exposure was in the many billions of dollars were able to be largely reversed by an approach of "defense-in-depth".
This standard seeks to normalize transaction creation, signing, delivery, and storage so integrity and security are baked into the process.
This specification is directed at several audiences:
Auditors: The specification enables auditors to assess whether a given system involved in the Blockchain Transaction Lifecycle meets the requirements specified here.
Developers and Service Providers: Transacation management service providers, and developers of tools to provide those services, can use this specification as guidance to ensure their tools and services implement best practice, providing secure management of transactions.
Users: End users of services and tools can use this specification, and more particularly assessments of conformance to it, to help determine whether a service or tool meets their requirements for security.
Policy Makers: This specification provides policy-makers with a broadly-backed guide to requirements for making tools and services that manage blockchain transactions secure.
This specification defines requirements for four functional Actors. An Actor works with a transaction and its bound metadata, in one of the following roles:
A single system can perform more than one of these services, and any of them can be performed by one system or a composition of several systems, applications, or components acting together.
Every normative requirement in this specification is an obligation on one or more of these Actors. Whether the Actor is a person, an automated process, a dedicated hardware device or a smart contract, the requirements are identical.
A system is assessed for conformance to this specification based on the services that it provides, against how it meets the relevant requirements for each type of Actor.
A Wallet is a tool for managing transactions, fulfilling the role of multiple Actors. This can provide a single convenient interface, and simplify the movement of transactions between Actors.
A User is a person or process (such as a software payroll system) that provides instructions to an Actor, for example to deploy a set of signed transactions at a specific time, or to create a particular transaction.
The term Consumer refers to whichever Actor a transaction is passed to next, for example a Signature Manager receiving a transaction from a Producer.
Transactions are moved between Actors, generally following the cycle Producer -> Signature Manager -> Deployer -> Indexer.
Transactions can be moved automatically from one stage to the next, for example by a Wallet that integrates the full Transaction Lifecycle, or can be received from one Actor and passed to the next by a User.
Several requirements apply to specific kinds of transaction. Two types are classified by their effect and one by its delivery timing. The axes are independent, so a single transaction may fall under more than one type.
By effect:
By delivery timing:
The key terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document MUST be interpreted as described in [RFC2119] as modified by [RFC8174] when they appear in all capitals, as shown here.
A valid statement of conformance to this specification MUST declare the types of Actor that the system assessed provides, and assess the system against the requirements that apply to each such declared Actor.
Requirements that list more than one Actor apply to any system that performs the role of any listed Actor.
Where a requirement refers to document, the relevant documentation MUST be available to any Actor that needs to act on the transaction or its metadata, and SHOULD be available publicly without restriction.
Where a requirement refers to maintain documentation, auditors MUST review the relevant documentation. Attesting conformance to this specification is an endorsement of the accuracy of such documentation.
Requirements are organized by the Actors they apply to.
A set of general requirements that apply to multiple types of Actor is follwed four requirement domain, one covering each specific type of Actor.
The lifecycle in the diagram (Generation, Signing, Delivery, Indexing) remains the narrative frame: transactions are constructed by a Producer, signed by a Signature Manager, delivered by a Deployer, and recorded by an Indexer. Integrity is verified at each handoff between Actors (see Verify Received Transactions and Communicate Transaction Data Securely).
Require
Strong Authentication
All Actors MUST
implement strong access control using industry-standard mechanisms
Purpose: Minimize the risk that unauthorzed parties can operate on transactions
Best practice is to implement automated Role-based access control to ensure timely update, with manual oversight.
For highly sensitive operations (such as confirming signature of large transactions, or Application Transactions) best practice includes confirming the operation through two distinct channels that use different transport and indentity verification, but for low-value transactions or operations that are not exposing key data this can introduce unjustifiable overhead.
It is acceptable to provide a "public" or "guest" Role, but setting configuration options per Enable Transaction Policies for Generation, Enable Transaction Policies for Signing and Enable Configured Policies for Deployment needs to be covered by appropriate access restrictions.
See also Communicate Securely, and see Implement Least Privilege, Review All Access, and Restrict PII Access in the BSSC General Privacy and Security Guidelines [GSP].
Tamper-Proof
Logs
Logs MUST be immutable or tamper-evident
Purpose: Ensure that logs provide reliable information for auditing
Example approaches include using append-only store, hash-chaining, write-once-read-many (WORM) or immutable object storage for logs, or to provide external attestation of log integrity.
Retain
logs
All Actors MUST follow a log
retention policy that includes retaining logs for a minimum of 3
years
Purpose: Ensure that logs provide reliable information for auditing
It is important to consider any relevant legal requirements for data retention as well as operational goals.
Minimize
Personal Information Exposure
All Actors SHOULD minimize the exposure of Personally
Identifying Information (PII)
This includes separating recorded PII from other logged information and providing stricter access control, only exposing the information to parties who have an operation need to access it.
Purpose: Protect Personally Identifiable Information from malicious third parties, supporting user expectations and legal requirements about privacy
Document
Personal Information Handling
All Actors MUST document
their handling of Personally Identifying Information (PII)
Purpose: Provide transparency into management of sensitive data about users
This includes data used for authentication, "Know Your Customer" (KYC) and Anti-Money Laundering (AML) measures, and other customer management data.
Document
Hashing Process
All Actors MUST document each hashing algorithm used.
Purpose: Provide transparency for security properties and interoperability
It is important for interoperability that any role receiving a transaction can determine the hashing algorithm used.
In addition different hashing algorithms have different levels of collision-resistance, and in practice the level of security they provide changes over time. Documenting the hashing algorithms used supports informed decisions about which tools to rely on.
For example, [ERC-712] specifies a process for hashing and signing typed structured data.
Document
Signing Process
Each Role that signs transaction data MUST
document the signing process it uses,
including the signature scheme, the encoding of the signature, and any
domain separation applied. The documentation MUST cover any deviation
from a standard it refers to, and MUST be sufficient for another party
to reproduce the digest and verify the signature without tooling
supplied by the signer.
Purpose: Enable any role receiving a transaction to establish independently what was signed
Documenting the hashing algorithm alone is not sufficient. Standards for signing typed structured data, such as [ERC-712], are frequently implemented with variations, for example hashing part of a structure differently, and those variations are often recorded only in the tooling that implements them.
Where a digest can only be reproduced by the implementation that produced it, no other role can establish what was signed, however clearly the transaction is presented.
See also Document Hashing Process, Hash Transactions and Verify Received Transactions.
Enable
Canceling Transactions
Producers, Signature Managers, and Deployers MUST provide a mechanism to
cancel a transaction, that results in the
Actor securely deleting all artifacts with signed bytes, and activating
any on-chain mechanism to invalidate signatures for that
transaction.
Purpose: Enable secure transaction cancelation
This is particularly important for Stored Transactions, but is relevant to all transactions that have not been incorporated into a block.
Best practice is to emit a warning that a transaction has been canceled with a transaction identifier, enabling other Actors to cancel the transaction.
Check
Complete Hashes and Addresses
All Actors that perform Address or Hash verification
MUST compare entire addresses
Purpose: Protect against attacks that construct similar addresses
Verifying a subset like the first or last n bytes is not an uncommon procedure. However, it leads to vulnerabilities such as an address specifically constructed to have a matching subset. While it is harder to ensure that is the case with a hash, it also significantly reduces any integrity guarantee if only part of the hash is compared for verification.
Verify
Received Transactions
All Actors
MUST verify the integrity of the transaction and associated metadata
upon receipt, ensuring the transaction bytes implement the intents
expressed in the metadata attached by the Producer, and MUST cancel any transaction that fails
verification.
Purpose: Ensure transactions match the intent expressed on creation
It is important to verify that if a "Time To Live" or expiry time for the transaction has passed then the actor cancels the transaction.
Best practice for Actors that incorporate a User Interface is to show the intents expressed in the metadata alongside the correspondinf features of the transaction itself.
See also Render from Signed Bytes
Manage a Secure Software Supply Chain
All Actors MUST maintain a secure Software supply chain, including:
Purpose: Manage software supply chain attack surfaces
Removing a component warrants the same scrutiny as adding one. Dropping a library that performs validation, for example, can weaken a service as much as introducing an unknown dependency.
Beat practice is to minimize dependencies to Software that is operationally necessary
Document
Cryptography Migration Procedures
All Actors MUST document plans and any procedures for
cryptographic migration scenarios, including protocol-level transitions
to post-quantum algorithms.
Purpose: Provide transparency into resilience planning
Note that this requirement applies even if the Actor has no planning, or their planning is only to copy changes made upstream in software they use.
See also Document Supply Chains
Prepare
for Cryptography Migration
All Actors SHOULD maintain
operational readiness to adopt updated cryptographic schemes in
accordance with protocol governance timelines.
Purpose: Ensure Actors can respond to changes in the cryptography environment in a timely manner
Implement
Readability Standards
All Actors
that provide a user interface MUST implement recognized best practices
for presenting transaction information optimised for human
readability
Purpose: Help people to understand and verify transaction data.
Render
from Signed Bytes
All Actors that
provide a user interface MUST derive any rendering of a transaction
optimised for human readability from the transaction bytes themselves,
and MUST NOT derive it from a request, an intent, or other metadata
accompanying them.
Purpose: Ensure that what a person reads describes what the transaction does
A rendering produced from the request that prompted a transaction, rather than from the transaction itself, can differ from it, whether through error or through deliberate manipulation, and a person reading it has no way to detect the difference. For a Signature Manager the bytes in question are those presented for signature, and for an Indexer they are the bytes recorded for the transaction.
Metadata attached under Attach Vital Metadata can usefully be displayed alongside the rendering, so that a person can compare the intent that was declared with what the transaction does. It is not a substitute for rendering the bytes.
See also Implement Readability Standards and Present Crucial Information in Readibility-optimised form.
Present
Crucial Information in Readibility-optimised form
Signature Managers, and Deployers, that provide a user interface, MUST
present account addresses and transfer values in a form optimised for
human readability
Purpose: Help people to understand and verify transaction data.
This information is crucial to making well-informed decisions, in particular regarding whether to sign and deploy transactions, and in configuring policy.
For example, [ERC-7730] is a widely implemented proposal for metadata describing how to present EVM contract calls and typed data in a form suitable for a person to read before signing. As it is a draft, implementing it is not formally required by Implement Readability Standards, but it is a good approach to use for meeting this requirement effectively.
See also Expose Transaction Value for Verification
Present
Readibility-optimised Information
All Actors that provide a user interface SHOULD
present information in a form optimised for human readability
Purpose: Help people to understand and verify transaction data.
While software effectively processes regular data formats, many of blockchain's native data formats are difficult for humans to process accurately. For example, Ethereum account addresses are subject to various well-known reading errors, and are therefore less useful as a presentation format in a user interface than offering a name that a user has previously decided to associate with a given address.
As well as the Crucial Information covered by Present Crucial Information in Readibility-optimised form this requirement covers Smart Contract code for deployment, function calls, and other information that is generally stored and transferred between tools in a machine-optimised format.
Maintain
Transaction Integrity
A transaction's payload and metadata
MUST NOT be changed except:
Any other software that transfers transactions MUST NOT change transaction payloads or metadata.
Purpose: Reduce the risk of transactions being altered in ways that could have undesirable consequences
Communicate
Transaction Data Securely
All Actors that transmit transaction data MUST use
communication channels that provide appropriate protection against
unauthorized disclosure, modification, replay, and impersonation.
Purpose: Reduce the risk of transaction data being altered in transmission
Channels vulnerable to "man-in-the-middle" alteration can change data in transit, undermining the integrity of the delivered data.
One powerful (but somewhat expensive) approach to securing communication is to use parallel channels with independent transport and identity verification, verifying that the communications on the two channels match, as a protection against one of them being compromised.
Note that the highest security channels available can introduce significant overhead, and this requirement needs to be applied with reference to the context, balancing the cost in terms of effort and complexity against the value that is at risk.
See also Require Strong Authentication]
Expose
Transaction Value for Verification
All Actors MUST expose the amount transferred,
including the decimal point and the type of token/coin, in a form
sufficient to verify it is correct.
Purpose: Ensure transaction values are accurately represented
Best Practice in user interfaces includes exposing the equivalent value in other currencies, whether fiat currencies such as Euros, or well-known cryptocurrencies such as Ethereum, according to configurable settings.
Where a converted value is exposed, best practice is to state the timestamp of the conversion and the source of the rate used, and to make clear that the converted figure is indicative rather than binding.
Producers MUST
document all information used to generate
transaction bytes, to enable deterministic reconstruction from explicit
inputs.
Purpose: Ensure that transactions are reproducible, both for audit purposes and for convenience.
In a number of situations, producers add information that is incorporated into the transaction bytes generated for signature and deployment. To ensure the security and integrity of transactions can be verified, it is necessary that all the information used is available.
For example, incorporating hidden default values or introducing time-based randomness violate this requirement.
Attach
Vital Metadata
Producers MUST
attach a canonical metadata envelope, cryptographically bound to the
transaction, that includes the explicit inputs, the unsigned transaction
bytes, and the intent, sufficient to deterministically reconstruct the
transaction (see No Hidden
Defaults).
Purpose: Enable integrity verification
A non-normative example of a metadata envelope is given in Practical Transaction Lifecycle Examples.
Attach
Useful Metadata
Producers
SHOULD include context such as destination, required signer set, policy
tags, destination chain or network, gas/fee policy, and expiry or time
to live (TTL) in the metadata attached for Attach Vital Metadata
Purpose: Expand metadata available to meet further use cases
Validate
Transactions for Each Chain
Producers MUST validate that constructed bytes
conform to chain-specific serialization and field constraints.
Purpose: Ensure that transactions meet the specific requirements of each blockchain where they will be deployed, so chain-specific differences do not cause unexpected transaction behavior or outcomes.
Log
Transaction Creation
Producers
MUST log each creation event including its timestamp, producer ID,
authenticated caller identity, request parameters, and
network/chain.
Purpose: Provide transparency and auditability
Hash
Transactions
Producers MUST
provide the Consumer a signed cryptographic
hash that covers the exact bytes of each transaction, and relevant
metadata, in a canonical form.
Purpose: Enable integrity verification at other steps in the transaction lifecycle
This is important to downstream Actors, to enable end-to-end comparison and verifying integrity.
See also Verify Received Transactions and Verify at Point of Delivery
Use
Hardened Environments
Producers
MUST generate transactions involving sensitive data or key-derived
parameters in a hardened environment with memory isolation and process
sandboxing.
Purpose: Protect sensitive information in transactions from malicious third parties and from accidental exposure
See also Enable Transaction Policies for Generation
Validate
Inputs
Producers MUST validate
and sanitize all inputs before transaction construction to prevent
injection or malformed data.
Purpose: To prevent malicious data injection, and processing of malformed data that will lead to a failed transaction.
Where inputs are generated from onchain data, best practice is to execute the method for retrieving the data at production time to ensure the retrieved input matches expected input.
Limit
Gas Fees
Producers MUST bound
gas/fee estimates within configurable limits and reject transactions
exceeding thresholds without explicit approval.
Purpose: Provide control of the risk that transaction costs are unexpectedly high
See also Enable Transaction Policies for Generation
Simulate
Transactions
Producers SHOULD
expose the results of simulating transactions against the current chain
state.
Purpose: Provide information on the real effects of a transaction before it is signed and deployed
See also Validate Transactions for Each Chain
Reject
Unauthorized Construction
Producers MUST reject construction requests
that are unauthenticated or unauthorized.
Purpose: Reduce the risk that a transaction is created by a malicious third party attempting to have it signed and deployed unwittingly
See also Enable Transaction Policies for Generation
Mitigate
Timing Attacks
Producers SHOULD
mitigate the effects of Timing
Attacks (MEV) on the set of transactions
Purpose: Protect against excess loss of value, or other harmful impacts of timing attacks
There are various mitigation strategies available, for example using private transaction submission, deadline and slippage bounds, commit-reveal ordering, or batching.
Verify
Transaction Sets
Producers that
construct a related set of transactions SHOULD expose the complete set
together, in a form sufficient to verify it performs exactly the
intended actions with no missing and no extra steps.
Purpose: Ensure that multiple transactions are appropriately linked without performing unnecessary steps or skipping important safeguards.
Apply
Transaction Policies to Generation
Producers MUST enforce configured policy such
as maximum amounts, denylists/allowlists, and velocity controls before
creating a transaction.
Purpose: Ensure that transactions are created as expected.
Enable
Transaction Policies for Generation
Producers MUST provide a mechanism to configure
policies covering
Purpose: Enable configurations relevant to the specific requirements for Producers
Note that while access allowlists and denylists are important, it is acceptable to provide an open policy treating all users as "public" or "guest", or fixed lists.
Best practice is to allow configuration of aspects including allowlists and denylists, velocity controls, maximum transaction amounts, and the like.
See also Use Hardened Environments, Limit Gas Fees, and Reject Unauthorized Construction.
Log
all signature requests
Signature Managers MUST logging of all
attempts to sign a transaction with the public key of the signer, the
transaction and its metadata envelope, the time, whether the transaction
was successfully signed, and if not a reason for failure.
Purpose: Provide information to enable forensic analysis
Validate
Allowed Signers
Signature
Managers MUST maintain an allowlist of permitted signing addresses
and MUST reject attempts to sign a transaction from addresses not on the
list.
Purpose: Ensure that transactions are not signed by an unauthorized party, and that adding an authorized signer provides sufficient friction to incentivize careful usage without imposing warning fatigue that leads to insecure workarounds becoming a habit.
This requires that adding an authorized address for signature is either an explicit step that isn't part of signing, or that attempting to sign from an unauthorized address will not succeed unless there is a specific action to accept the new address as authorized.
Compare
Old Transactions
Signature
Managers SHOULD provide a mechanism to compare a transaction
proposed for signing against previously signed transactions.
Purpose: Help verify that a transaction is similar to previous transactions, and identify accidentally and incorrectly anomalous transactions before deploying them.
Require
Multiple Signers
Signature
Managers MUST enable multi-signature approval policies
Purpose: Ensure that high-value or sensitive transactions can have an appropriate safety threshold of multiple signers for approval
For high-value or sensitive transactions it is often important to ensure that no single individual can authorize a transaction.
Verify
Correct Ordering
Signature
Managers MUST ensure correctness of ordering in transactions if more
than one is being handled.
Purpose: Prevent submitting an ordered set of transactions that will not successfully complete according to the intent, which would therefore waste the effort and gas/fees consumed.
Best practice is generally to make initiation rely on successful completion of the preceding transaction.
Surface
Timing Attack Warnings
Signature Managers SHOULD surface a
warning about possible Timing
Attacks on the set of transactions.
Purpose: Highlight any risk that a transaction will be subject to a Timing Attack, and help mitigate that risk
Apply
Transaction Policies to Signing
Signature Managers MUST enforce
configured policy such as maximum amounts, denylists/allowlists, and
velocity controls before signing a transaction.
Purpose: Ensure specific configuration settings for signature are respected by the Signature Manager.
Enable
Transaction Policies for Signing
Signature Managers MUST provide a
mechanism to configure policy identifying
Purpose: Enable safeguards relevant to specific circumstances for signatures
Best practice is to enable a range of policy controls including transaction value limits, denylists, and velocity controls before signing a transaction.
Verify
Bytecode
For Application
Transactions, Signature
Managers MUST verify that the bytecode of any contract to be
deployed is accurately built from the declared source code before
signing.
Purpose: Ensure Application Transactions are only signed when the code they deployed is verified
Verify
Access Control
For Application Transactions, Signature Managers MUST ensure that
initialization of a proxy contract is atomic, or enforces strong Access
Control, before signing.
Purpose: Ensure Application Transactions are only signed when the code they deploy is protected against unauthorised initialization
Implement
Upgrade Safety Controls
For high-impact Application Transactions (e.g., upgrades
to core protocol contracts), Signature
Managers SHOULD require time-locks or multi-party approval before
signing.
Purpose: Enable safeguards to protect against "blind" signing high-impact Application Transactions
Where a signer alone lacks the context or capability to perform these verifications, the Signature Manager role MUST be composed of additional systems that can (see Roles).
Secure
Stored Signed Transactions
Signature Managers MUST securely store
signed transactions whose delivery to a Deployer is deferred, encrypted, with strong
access control mechanisms
Purpose: Ensure that Stored transactions are only deployed as intended, and cannot be accessed and deployed maliciously or by accident
If a deferred transaction is sent for deployment at a time other than when the signer expects, it can lead to unexpected and harmful consequences.
Delivery requirements vary by transaction type and urgency. As well as requirements that apply to Deployers　independently of the type of transaction being deployed, some specific requirements for each transaction type is defined below:
Verify
Deployment Authorization
Deployers MUST verify and log approval for the
transaction before delivery.
Purpose: Ensure that transactions are not deployed without approval.
While this could be a simple request, especially in the case of a high-value transfer or a high-impact Application Transaction it could include a record of a Governance vote, a change management approval, security review sign-off, or a combination of these along with other elements.
See also Require Strong Authentication, Apply Configured Policies for Deployment and Enable Configured Policies for Deployment.
Log
All Delivery Attempts
Deployers
MUST log all delivery attempts with information including:
Purpose: Ensure records are sufficient for forensic analysis
It is important to note that different finality policies apply to diffierent blockchains, so these need to be taken into account is determining what is a "successful transaction".
Deployers SHOULD only broadcast transaction
deployment requests to RPC nodes on a configured allowlist
Purpose: Reduce risk of timing attacks and malicious behavior by RPC nodes
See also Enable Transaction Policies for Deployment
Manage
Retried Deliveries
Deployers
MUST implement retry logic suitable for transient failures.
Purpose: Minimize network congestion and the risk of incurring penalties for perceived attempted Denial of Service
As a minimum, implementing a simple Exponential Backoff [WB-EP] meets this requirement.
Best practice is to monitor the network for transient failures, preventing repeated delivery attempts during network outage or RPC failures and delaying repeated attempts successively longer, to minimize the potential effect of replicating a Denial of Service Attack as well as any penalty designed to protect against such attacks, and to minimize contributing to network congestion.
Verify
at Point of Delivery
Deployers
MUST verify transaction integrity (via cryptographic hash comparison)
immediately before broadcast to detect any tampering during transit or
storage.
Purpose: Ensure that the transaction deployed is the transaction intended
Monitor
Delivery Latency
Deployers
SHOULD monitor delivery latency and time to execution, and emit an alert
when transactions are not executed within defined thresholds.
Purpose: Ensure that occurrences of anomalous deployment or transactions failing to be executed according to expectations can be tracked, so appropriate remedial action can be taken, such as adjusting policies for Gas/fees to ensure faster (or slower) execution
The appropriate alerting mechanism depends on how the Deployer is integrated: a Deployer embedded behind a single interface may raise the alert through that interface, while a Deployer called by other software is more likely to emit an event or warning.
Apply
Configured Policies for Deployment
Deployers MUST enforce configured policy such
as approval requirements, maximum amounts, denylists/allowlists, and
velocity controls before deploying a transaction.
Purpose: Ensure that deployment meets expectations set
Ignoring configured policy makes the software fundamentally unreliable.
Enable
Configured Policies for Deployment
Deployers MUST provide a mechanism to configure
policies including:
Purpose: Enable safeguards relevant to particular circumstances, and configuration needed to meet other requirements.
Best practice is also to enable policies including
Limit
Transaction Changes at Delivery
Deployers MUST NOT change transaction payloads
and metadata except to
Purpose: Ensure Deployers do not impact transaction Integrity
Deliver
Transactions Promptly
Deployers
MUST promptly deliver transactions according to the transaction's
expressed intent.
Purpose: Ensure that transaction deployment time meets expectations, helping avoid excessive impacts of market volatility and other transactions deployed.
In general, signed transactions are meant to be submitted immediately on receipt. However in some cases transactions are signed, but only intended for deployment when some trigger condition occurs, and until then are meant to be stored ready for deployment.
Possible triggers can include a particular transaction occurring, an asset or the transaction price ("gas fee") reaching a particular price, or some amount of time passing, among other events.
This requirement does not oblige Deployers to enable any specific instructions to be given, only to meet the expectations for services they explicitly provide, but see also Enable Configured Policies for Deployment
Ensure
Delivery Capacity
Deployers
SHOULD ensure delivery infrastructure has sufficient redundancy to avoid
delays due to single points of failure.
Purpose: Ensure that deployments are resilient to transient failures and single points of failure
Re-verify
Application Transactions
Deployers SHOULD re-verify bytecode correctness
and access-control safety for Application Transactions before
broadcast.
Purpose: To ensure that the code being deployed is as expected, and as reviewed for security.
If a Proxy Contract can be initialized multiple times, and if there is not strong Access Control on the capability to initialize the Contract, it exposes the Smart Contract System to malicious attack.
Implement
Protected Delivery Paths
Deployers SHOULD enable protected delivery
paths that limit the visibility of transactions before they are included
in a block.
Purpose: Minimize exposure to Ordering Attacks
A transaction broadcast to a public mempool is visible to every participant on the network while it is pending, increasing the potential for Ordering Attacks.
Apprpriate mechanisms include submitting directly to a block producer, private relay or bundle endpoints, connections to a validator that bypass public transaction gossip, and encrypted or threshold-encrypted mempools. Raising gas or fee parameters is not a protected delivery path. Where a network does not make pending transactions publicly visible, this requirement is met by the network's design.
Best practice includes
See also Mitigate Timing Attacks, Surface Timing Attack Warnings, and Broadcast to Authorized RPC Nodes
Stored Transactions are deployed when triggered by protocol events or requests, and can have protocol-imposed delays before they can be executed.
Secure
Stored Transactions
Deployers
MUST securely store signed transactions whose delivery is deferred,
encrypted, with strong access control mechanisms
Purpose: Ensure that Stored transactions are only deployed as intended, and cannot be accessed and deployed maliciously or by accident
If a deferred transaction is sent for deployment at a time other than when the signer expects, it can lead to unexpected and harmful consequences.
Monitor
Stored Transaction Deployment Triggers
Deployers MUST implement monitoring of triggers
to deploy Stored
transactions.
Purpose: Ensure Stored Transactions are deployed in a timely manner, once the deployment conditions are met
Allow
Batching and Throttling
Deployers SHOULD provide a mechanism to batch
or throttle transactions where this can save gas.
Purpose: Minimize Gas or Fees for deployment.
Use
Tamper-resistant Transaction Storage
Indexers MUST read transaction data from a
tamper-resistant source.
Purpose: Ensure the Indexer presents accurate information
This can include reading the data directly from a blockchain node, or a database or other local storage mechanism, so long as it ensures the data the Indexer provides is reliable.
Index
Successful Transactions
Indexers
MUST accurately reference the block(s) that included a transaction it
records
Purpose: Ensure the Indexer presents accurate information
Document
Finality
Indexers SHOULD document the policy it uses to classify a
transaction as finalized.
Purpose: Demonstrate the method used to determine finality for a given transaction, and understanding of network-specific finality
See also Index Transactions' Finality
If an Indexer identifies that an almost-identical transaction has been deployed multiple times (typically only changing the nonce), this information is also helpful.
Present
Transactions Accurately
Indexers
MUST accurately represent all transaction data it records.
Purpose: Prevent misleading information being used to make decisions
Any misleading representation of transaction data is a major security risk, that can lead to harmful decisions based on inaccurate data, whether through misapprehension or deliberate deception.
Index
Transactions' Finality
Indexers
SHOULD provide finalization status for transactions they record.
Purpose: Provide clarity on the likelihood of a transaction being reversed after being indexed as incorporated in a block
While for blockchains that have deterministic finalization this is typically straightforward, in many cases finalization is effectively optimistic, and the most accurate approach is to determine status based on re-organisation history.
Index
Failed Transactions
Indexers
SHOULD record relevant transactions that were deployed but not
incorporated in a block, along with useful metadata.
Purpose: Help understand why transactions failed
Understanding why a deployed transaction was not accepted can inform future transaction construction.
Other than a Transaction failing to validate, there are many possible contributing factors to it not being included. Useful information in this situation could cover
"General Security and Privacy Guidelines", Ed. Joe D'Annolfo, Chaals Nevile, Blockchain Security Standards Council 2025. Available at https://specs.blockchainssc.org/gsp
"Typed structured data hashing and signing", Remco Bloemen (@Recmo), Leonid Logvinov (@LogvinovLeon), Jacob Evans (@dekz), Ethereum Foundation 2017. https://eips.ethereum.org/EIPS/eip-712
"Structured Data Clear Signing Format", Ethereum ERC-7730 (draft). https://eips.ethereum.org/EIPS/eip-7730
Adoption of the format is promoted by the Clear Signing Initiative. https://clearsigning.org/
"Exponential Backoff", WikiPedia. https://en.wikipedia.org/wiki/Exponential_backoff
"Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, IETF 1997. https://www.rfc-editor.org/rfc/rfc2119.html
"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", B. Leiba, 2017. https://www.rfc-editor.org/rfc/rfc8174.html
This document is version 1 of the Blockchain Transaction Lifecycle Security Standard, developed by the Blockchain Security Standard Council (BSSC Inc.). It is intended as a new publication.
Without explicit written permission, you cannot share, modify, copy or distribute this document.
The BSSC requests feedback on this document. Feedback can be provided through the BSSC Contact page.
NO WARRANTIES: THIS SPECIFICATION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, COMPLETENESS AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL BSSC, ITS MEMBERS OR ITS CONTRIBUTORS BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE SPECIFICATION.
THIRD PARTY RIGHTS: Without limiting the generality of the foregoing, BSSC ASSUMES NO RESPONSIBILITY TO COMPILE, CONFIRM, UPDATE OR MAKE PUBLIC ANY THIRD PARTY ASSERTIONS OF PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS THAT MIGHT NOW OR IN THE FUTURE BE INFRINGED BY AN IMPLEMENTATION OF THE SPECIFICATION IN ITS CURRENT, OR IN ANY FUTURE FORM. IF ANY SUCH RIGHTS ARE DESCRIBED ON THE SPECIFICATION, LICENSOR TAKES NO POSITION AS TO THE VALIDITY OR INVALIDITY OF SUCH ASSERTIONS, OR THAT ALL SUCH ASSERTIONS THAT HAVE OR MAY BE MADE ARE SO LISTED.