Parties + state
Who shares state, and what must be verifiable?
Protocol security laboratory
Blockchain engineering starts with the trust you cannot take back.
FISTA designs and engineers blockchain systems around explicit trust boundaries, on-chain state, off-chain services, keys, roles, upgrades, integrations, monitoring, and response. The first decision is whether decentralization is justified at all; the next is how to reduce irreversible risk across the full protocol lifecycle without claiming impossible security guarantees.
ON-CHAIN
- State + invariants
- Roles + upgrades
- Economic rules
OFF-CHAIN
- Oracles + bridges
- Services + indexing
- Monitoring + response
Every boundary introduces assumptions. The architecture review makes them visible before code makes them expensive.
On-chain decision tree
Should this system use blockchain at all?
Use blockchain when independent parties need shared, verifiable state, no single trusted operator is acceptable, and the cost of consensus, key management, limited mutability, and public or replicated execution is justified. If one accountable operator can safely maintain the system, a conventional architecture is usually simpler to build, secure, and operate.
QUESTION / 01
Do parties need shared state without one trusted operator?
Yes → inspect verification, incentives, and authority.
No → prefer a conventional service or database.
THEN →
QUESTION / 02
Can the trust model survive keys, upgrades, oracles, and incident response?
If the operational dependencies recreate a single opaque authority, the architecture needs another pass before implementation.
Bring the parties, state, authority model, integration assumptions, and failure cost—not a predetermined chain choice.
Review your protocol architectureProtocol layer blueprint
Where does protocol risk actually live?
Risk crosses layers. Contracts encode state and authority; key and governance systems control change; bridges and oracles import external trust; off-chain services translate protocol state for users; monitoring and response determine how quickly failure is understood. FISTA reviews these as one system instead of treating contract code as the whole security boundary.
01Interface layerWallets, applications, APIsSigning clarity · state accuracy · transaction intent
02Service layerIndexers, relayers, automationReconciliation · availability · hidden authority
03Protocol layerContracts, invariants, upgradesCorrectness · access control · economic behavior
04Trust layerKeys, governance, oracles, bridgesAuthority · external assumptions · emergency action
05OperationsMonitoring, response, changeDetection · escalation · recovery evidence
Architect / build / review / operate
How does security follow the protocol lifecycle?
Security decisions begin in architecture, continue through implementation and independent review, and remain active after deployment through monitoring, governance, and incident preparation. FISTA defines the evidence and responsibilities at each stage. A review can reduce uncertainty; it cannot erase the operational and economic risks of a live protocol.
- 01
Architect
Trust model, on/off-chain boundary, roles, invariants, integrations, upgrades.
Threat model - 02
Build
Explicit state transitions, least privilege, tests, tooling, documentation.
Implementation evidence - 03
Review
Assumptions, scenarios, properties, vulnerabilities, fixes, residual risk.
Review record - 04
Operate
Monitoring, governance, key procedures, response, safe change.
Operating controls
Attack-surface ledger
What should a protocol threat ledger make visible?
A useful threat ledger names each surface, how it can fail, the evidence that reduces uncertainty, the owner responsible for control, and the residual risk that remains. It stays connected to architecture and operations rather than becoming a decorative checklist. FISTA uses it to prioritize review and make tradeoffs reviewable.
| Surface | Representative risk | Evidence / control |
|---|---|---|
| On-chain state | Incorrect transitions, invariant failure, economic manipulation | Properties + scenario tests + review |
| Keys + roles | Privilege concentration, compromised signers, unsafe rotation | Least privilege + role map + procedures |
| Upgrade path | Unexpected authority, storage risk, governance failure | Explicit policy + compatibility checks |
| Oracles + bridges | Stale data, trust mismatch, cross-domain failure | Source assumptions + failure modes |
| Off-chain services | Indexing drift, API failure, hidden centralization | Reconciliation + observability |
| Response | Slow detection or unclear emergency authority | Monitoring + escalation + rehearsed action |
Review evidence format
- Scope + version
- Trust assumptions
- Finding + severity rationale
- Reproduction evidence
- Remediation + verification
- Residual risk + owner
Architecture review intake
Make every trust boundary explicit before deployment.
The review starts with the architecture and authority model—not a request for a security guarantee.
Review your protocol architectureAuthority
Keys, roles, governance, and emergency powers
Change
Upgrade path, migration, and compatibility assumptions
Dependencies
Oracles, bridges, services, interfaces, and monitoring
01What blockchain services does FISTA offer?+
FISTA supports trust-model and protocol architecture, smart contract engineering and review, decentralized application services, integrations, and operating infrastructure. Scope is shaped around the actual protocol lifecycle and threat model rather than a generic Web3 bundle or an unsupported claim of universal chain expertise.
02Does FISTA review existing smart contracts?+
FISTA can inspect contracts for correctness, access control, state transitions, integration assumptions, upgrade behavior, and common vulnerability patterns. The engagement defines its depth and evidence clearly. A review reduces risk but is not represented as a guarantee that deployed code can never fail or be exploited.
03Which chains and standards does FISTA work with?+
FISTA evaluates the ecosystem, execution model, tooling, standards, interoperability needs, and operating requirements for the protocol. Major EVM and L1/L2 patterns may be relevant, but the architecture review determines fit rather than presenting a fixed chain list as proof of capability.
04Is blockchain the right fit for my project?+
Blockchain is justified when multiple parties need shared, verifiable state without relying on one trusted operator, and when the cost of decentralized coordination is acceptable. If a conventional service or database provides the required trust more safely and simply, FISTA will recommend the simpler architecture.