Deployment is a decision about where the network components run, who operates them, how teams reach them, and how change and recovery are handled. The product supports a managed delivery arrangement and institution-hosted or on-premises scope subject to assessment and agreement. Those options do not change who owns the bank’s asset policies, reserves, customer records, governance decisions, or business commitments.
Topology is not a universal diagram that can be selected without workload and dependency discovery. Validator placement, RPC exposure, explorer access, regions, storage, monitoring, backup, and integrations need to fit the institution’s requirements and approved environment. Capacity, resilience, recovery objectives, maintenance windows, and service levels are defined for the particular deployment; none should be assumed from a package name.
Design a topology around real dependencies
A deployment design identifies the network, authorized validators, RPC access paths, explorer components, administrative access, and relevant institutional applications. It also shows trust boundaries and dependencies such as identity services, key custody arrangements, monitoring, storage, and external vendors. The final placement and connectivity are confirmed through technical discovery rather than presumed from a generic reference architecture.
The institution should provide expected workloads, access patterns, hosting constraints, regional requirements, network security standards, data-handling rules, and operational contacts. The delivery team can then assess component placement, resource assumptions, access separation, and failure considerations. A diagram is a planning artifact, not evidence of a live customer environment or a guarantee of capacity or availability.
Illustrative deployment components
- Agreed access boundaryConfigured RPC, administrative access, and permitted network paths.
- Network and validatorsDedicated EVM network with validator topology established for the engagement.
- Explorer and operationsAgreed network visibility, monitoring, maintenance, and support components.
Compare managed and institution-hosted duties
With fully managed delivery, FusionPointAI operates the infrastructure and services explicitly included in the agreed scope. The institution still owns its banking policies, asset issuance and backing, customer records, governance authority, business approvals, and integration responsibilities assigned to it. The contract should state the covered components, access model, support boundaries, maintenance approach, and any agreed continuity services.
For bank-hosted or on-premises delivery, the institution provides and operates the approved hosting environment while FusionPointAI supplies the agreed software license, implementation, integration, upgrades, and technical support. The division of duties must cover infrastructure access, monitoring, backups, change windows, recovery, and incident coordination. This model requires custom quotation and feasibility review; source-code ownership does not automatically transfer.
Plan maintenance, recovery, and upgrades
Continuity planning begins with component dependencies and failure scenarios: loss of an application connection, unavailable infrastructure, impaired validator participation, storage or backup issues, and identity or key-service disruption. The institution and provider should agree monitoring responsibilities, incident communications, recovery prerequisites, decision authority, and the evidence needed to resume operation. Recovery objectives are specific design and contractual decisions, not automatic product properties.
Software maintenance and network upgrades require coordinated ownership. Chain ID is immutable after network creation, while supported mutable parameters follow governance and some changes require coordinated technical upgrades. Define how changes are assessed, approved, tested, scheduled, communicated, and rolled back where feasible. Document which party prepares changes and which institutional authority approves operational impact before production rollout.
Responsibility varies by deployment model
Managed: provider operates agreed scope. Hosted: institution operates its approved environment.
FusionPointAI provides implementation and software services as contracted.
The institution retains policy, issuance, reserves, customer records, and business duties.
Coverage, recovery roles, objectives, and escalation are written into the agreement.
Leave discovery with concrete decisions
Before implementation, confirm hosting ownership, target environments, validator and RPC scope, explorer exposure, identity and key boundaries, integration dependencies, workload assumptions, and regional constraints. Record unresolved feasibility questions rather than converting them into assumed features. The institution should identify technical, security, operations, finance, and governance decision makers who can approve their respective parts of the design.
Expected planning outputs include an agreed topology, component and responsibility inventory, integration boundary, security assumptions, operational procedures, continuity requirements, upgrade process, and test and handover criteria. Commercial documents then state support coverage, capacity assumptions, service levels, and recovery commitments if any. A production service begins only under separately reviewed scope, formal quotation, and executed agreement; submitting requirements does not provision a network.