NFT Development

Sphere 10 develops NFT applications around the asset and the business process it represents. We build membership platforms, digital certificate registers, collectable products and transferable entitlements, including the contract, customer interface, .NET backend and administration tools. The design connects on-chain ownership with the information and operational actions your product needs, from issuance and transfer to support and reconciliation.

The useful starting point is a clear asset lifecycle. Who can issue an item, what does a holder receive, how can it move and what happens when information changes? We translate those answers into contract rules, metadata, access checks and understandable user journeys. ERC-721 or ERC-1155 can supply standard interfaces on EVM networks, while application services manage the surrounding business records. We engineer the complete system, including wallet interactions, event processing, content retention and the tools your team uses after launch.

💡 Define the Entitlement Precisely — Describe what holding the asset permits and which system enforces it. That decision connects token ownership to a useful product experience.

Specify the Asset and Its Lifecycle

We define issuance, ownership, transfer, expiry or revocation behaviour around the actual product. A certificate, a membership and a collectable edition have different requirements. The specification identifies which rules are enforced by the contract and which belong to the application's service or administration layer.

On Ethereum and compatible EVM networks, ERC-721 models individually identified assets and ERC-1155 supports multiple asset types in one contract. We implement mint/burn authority, transfers, approvals and metadata updates using selected OpenZeppelin components. ERC-2981 supplies royalty information; payment behaviour still depends on the receiving marketplace. For Solana work, we assess Metaplex Core for new assets and Token Metadata compatibility for existing collections against the required wallets and marketplaces.

Define minting authority, transfer behaviour and administrative roles.
Separate token identity from mutable descriptions and private customer information.
Specify content storage, retention and metadata-update responsibilities.

Build the Product Around the Contract

Nethereum connects C# services to EVM contract calls and events. ASP.NET Core exposes the application operations used by the customer interface and administration tools. Sphere10 Framework supplies reusable application and data infrastructure, while your product owns its asset rules, eligibility and customer records.

The surrounding application tracks contract addresses, token identifiers, ownership events and content references separately from customer records. BlockchainSQL Server demonstrates Bitcoin ingestion into a relational database and explorer; the same checkpoint/rebuild discipline informs an NFT indexer's design. EVM adapters use Nethereum, while a Solana asset uses its own program/account interfaces. IPFS content identifiers require a pinning and retention plan so referenced metadata and media remain available.

Create wallet flows for connection, transaction review and confirmation status.
Keep submitted transactions distinct from confirmed ownership and entitlements.
Provide administration for permitted issuance, asset lookup and support investigation.

Test Ownership, Events and Adverse Paths

Acceptance follows the complete asset journey on the agreed test network: issue, inspect, transfer and use the entitlement. We test rejected signatures, insufficient funds, unavailable providers and interrupted submissions. The interface explains what remains pending and which actions the user can safely take next.

Contract tests cover unauthorised minting, receiver behaviour, approval changes, supply limits and any pause, rental or entitlement rules the product implements. Indexing tests replay duplicate events, restart from checkpoints and reconcile chain changes before updating derived ownership views. We exercise metadata changes and unavailable gateways alongside the customer journey. Independent contract review can be a release milestone against the specified source and deployment configuration.

Verify contract rules for permitted and rejected operations.
Test replayed events, delayed confirmations and indexer restart recovery.
Check wallet/account changes and access decisions using actual asset state.

Deliver Source and Operational Ownership

We provide contract source, deployment configuration, ABI artifacts and the application code with a record of deployed addresses. The handover identifies keys, administrative permissions, metadata hosting and the services needed to operate the product. Your team can reproduce the build and trace a customer issue through its transaction and application records.

The release record identifies network, deployed program or contract, ABI/schema, administrative authority and metadata update policy. Operators receive minting/reconciliation tools, monitoring and documented content retention. Acceptance follows issue, inspect, transfer and use of the asset through the real application, with the selected wallet and marketplace integrations. Source and deployment procedures make subsequent collection changes traceable to the accepted contract and application baseline.

Retain deployment addresses, contract versions and environment configuration.
Demonstrate support lookup from customer record to relevant chain activity.
Document key custody, privileged actions and recovery responsibilities.

Technologies & Integration

ERC-721 — Distinct-token ownership, approvals and transfer interfaces, tested with the intended receiving contracts and wallets.
ERC-1155 — Multi-token balances and batch operations for editions or asset classes that share a contract.
OpenZeppelin Contracts — Selected token, access-control and upgrade components configured around explicit asset and administrative rules.
Nethereum — C# EVM calls, transaction receipts and event processing around an ASP.NET Core application and relational read model.
IPFS — Content-addressed metadata/media with deliberate pinning, availability checks and retention ownership.

Discuss Your Project Back to Services

Full-Stack MVP Development

Sphere 10 takes blockchain product ideas through to a working first release. We deliver the customer interface, application services, contract or node integration, data storage and deployment as one coherent product. The MVP is shaped around a business journey people can complete: issue a credential, transfer an asset, reconcile a payment or inspect independently verifiable records. That journey gives the build a useful commercial and technical boundary.

Our usual application foundation is C# and ASP.NET Core, with Blazor or an appropriate web interface and the chain-specific components the product requires. We define the authoritative state, transaction lifecycle and operator actions before expanding features. Our BlockchainSQL Server work provides a concrete reference for ingestion, processing, relational storage and explorer presentation. We bring that end-to-end engineering approach to your first release, retaining a clear path from customer action through the chain to a supportable application result.

💡 Choose the First Transaction That Matters — Define one complete customer outcome and the operator actions needed to support it. That gives the MVP a concrete scope and acceptance journey.

Turn the Proposition Into a Buildable Journey

We identify the user, the transaction or record the product exists to enable and the evidence of success. The initial scope includes the steps needed to complete and support that journey. Account creation, wallet connection, permissions and administration are considered alongside the visible product feature.

Project Design selects a working vertical slice and its dominant stack: ASP.NET Core/C# business APIs, a Blazor or React/TypeScript web interface, or MAUI when an installed mobile client is required. SQL Server or PostgreSQL holds the authoritative application records. We define the first useful journey, integration dependencies and measurable acceptance examples before expanding the backlog, so the MVP can validate the proposition through a complete working product.

Define customer and operator roles with a complete start-to-finish workflow.
Identify authoritative records, transaction states and external dependencies.
Agree acceptance examples before committing the implementation scope.

Implement Every Layer of the Working Product

ASP.NET Core services own business operations, access checks and integration. A Blazor or selected web interface presents the customer journey, while adapters isolate payments, messaging, external APIs or a blockchain node when those capabilities belong in the product. The application data model supports query and administration and records the difference between an accepted request and its completed external outcome.

Sphere10 Framework contributes compatible application composition, persistence, serialisation and logging infrastructure. OpenID Connect authentication and server-side authorisation protect the chosen workflow; billing, messaging and other providers receive explicit adapters where required. BlockchainSQL Server is a reference for ingestion and a usable data interface when chain-backed data belongs in the proposition. Each selected component has a clear contract and operating owner.

Build the user journey and the administration needed to operate it.
Persist transaction identity, processing state and relevant chain context.
Provide a repeatable deployment and environment configuration.

Prove Behaviour Across the Complete Journey

Acceptance uses representative records and the accounts required by the agreed environment. We test rejected actions, lost responses, delayed external outcomes and service restarts with work outstanding. A customer can tell whether an action was requested, is still processing, completed or was rejected, while support staff can locate its operational history.

We test the boundaries that make the proposition work: identity, permissions, persistence and the critical external integration. Playwright can exercise the web journey while .NET tests verify application rules and failure recovery. Duplicate callbacks, provider outages and restarted workers receive recorded outcomes and reconciliation rules. Workload checks use the first release's expected records and concurrency, giving the next delivery phase an observed operating baseline.

Exercise a complete user journey including a rejected or interrupted operation.
Verify consistency between chain results, application views and operator tools.
Test restart recovery and duplicate handling at integration boundaries.

Hand Over an Accepted Product and the Next Decisions

Delivery includes application source, build instructions, deployment assets and a clear account of account, key and data ownership. Operators receive the diagnostic and recovery procedures needed for the released workflow. We record the tested environment and dependencies so your team can reproduce the product and investigate issues.

The agreed Project Design defines delivery scope, acceptance and the next prioritised decisions. Handover includes application source, schema migrations, configuration and deployment instructions; contract source and chain addresses are included when the product uses them. Operators receive diagnostics and recovery procedures for the released workflow. The follow-on backlog is grounded in the accepted build and observed user needs, with additional QA or continuing execution scoped explicitly.

Provide source, environment configuration and a practical operating runbook.
Retain acceptance records and a prioritised follow-on feature backlog.
Define ongoing monitoring, support and change ownership explicitly.

Technologies & Integration

ASP.NET Core — C# application APIs, authentication/authorisation and provider adapters for the complete first product journey.
Blazor — C# component-based web UI where appropriate, with React/TypeScript available when the product benefits from that ecosystem.
Nethereum — Optional EVM integration when contracts or chain-backed operations are part of the actual MVP proposition.
SQL Server — Authoritative relational records, migrations and queries; PostgreSQL is another selected provider where appropriate.
Sphere10 Framework — Compatible application composition, persistence, serialisation and diagnostics that support a maintainable first release.

Discuss Your Project Back to Services

POC Development

Sphere 10 builds proofs of concept that answer the technical question holding up a project decision. We investigate blockchain protocols, contract behaviour, node integration, data ingestion, cryptographic formats and performance-sensitive processing using focused executable experiments. The output is evidence you can inspect, reproduce and use to decide the next engineering step, with the test conditions and remaining uncertainties made explicit.

A useful POC starts with a specific decision: can a node provide the required history, can an indexer recover after a fork, or can a processing path sustain the intended workload? We define the hypothesis, representative inputs and acceptance threshold before building the harness. C# and our .NET infrastructure provide a productive foundation for these experiments, with native or chain-specific tools added where the question requires them. The result combines working code, measured observations and a clear recommendation for proceeding, revising the design or stopping.

💡 Write the Decision Before the Experiment — State what result would change the project plan. A measurable question keeps the POC focused and makes its conclusion useful to the business.

Turn an Assumption Into a Test

We identify the uncertain mechanism and separate it from the rest of the proposed product. Examples include transaction interpretation, contract lifecycle rules, import throughput, signing compatibility or an external provider's data completeness. The experiment uses a small scope that can produce a meaningful answer rather than a broad demonstration.

A .NET proof of concept starts with a falsifiable question: can an API meet the required latency, can a device SDK survive the intended lifecycle, or can a chain feed recover without losing records? We define representative input, expected output and pass/fail criteria before implementation. The experiment uses the actual provider, protocol, hardware or dataset boundary that could overturn the architecture decision.

Define the hypothesis and the decision its result will support.
Record representative datasets, workload shape and expected output.
Identify constraints and exclusions that limit the conclusion.

Build a Harness Around Real Boundaries

We implement the experiment against actual node APIs, protocol records and persistence mechanisms. Sphere10 Framework supplies useful binary serialisation, endian-aware reading, Merkle structures and transactional storage where relevant. These components support the harness while the experiment's evidence comes from the behaviour exercised for your requirement.

We build the smallest useful C# console harness, NUnit fixture or working UI around that boundary. Nethereum can exercise an EVM integration on the selected test environment; native interop can isolate a device or C/Rust library; an ASP.NET Core endpoint can expose an integration contract. BlockchainSQL Server's separation of input blocks, transformation and persistence illustrates how a processing POC can isolate bottlenecks and recovery behaviour.

Record dependency versions, configuration and the commands needed to rerun.
Retain input fixtures and machine-readable results where appropriate.
Expose intermediate states needed to explain success or failure.

Measure the Weak Cases as Well as the Happy Path

Correctness tests cover malformed records, duplicate inputs, incomplete history and restart during processing. Protocol experiments compare the result with an independent interpretation or known fixture where available. The test report distinguishes observed behaviour from assumptions that remain unexercised.

BenchmarkDotNet measures focused .NET code under controlled runtime and build conditions, including allocation effects where relevant. End-to-end timing separately captures network, disk and provider costs. We record dataset size, machine/runtime configuration, concurrency, cold-start versus steady-state behaviour and adverse inputs. The result explains the conditions under which the hypothesis held and the boundaries that still need a larger production experiment.

Exercise the failure that would invalidate the proposed architecture.
Repeat measurements and inspect variability before recommending a design.
Separate correctness evidence from throughput or resource-use observations.

Deliver a Decision Package That Can Be Reused

Handover includes source, fixtures, results and a recommendation to proceed, revise or stop. We explain what the experiment establishes and which production responsibilities remain. Useful prototype code can be identified for retention, while temporary scaffolding and untested assumptions remain visible in the delivery plan.

Delivery contains the runnable harness, source, fixtures, dependency versions and a concise decision record. That record ties measured evidence to the recommended architecture, remaining risks and implementation acceptance criteria. Your team can rerun the experiment when a provider, library or workload changes. A successful POC becomes an informed engineering input to the production design, with operational hardening and release acceptance scoped explicitly.

Provide a reproducible test procedure and the retained source artifacts.
Summarise findings, remaining risks and the next engineering decisions.
Translate validated assumptions into concrete build and acceptance requirements.

Technologies & Integration

NUnit — Repeatable .NET fixtures for the hypothesis, boundary cases and observed integration behaviour.
BenchmarkDotNet — Controlled .NET microbenchmarks with recorded runtime/build conditions and measurements appropriate to the question.
Nethereum — Selected EVM test-environment calls, receipts and event experiments when blockchain integration is the uncertain boundary.
Sphere10 Framework — Existing compatible application, data, serialisation or protocol mechanisms used to isolate the experiment's actual risk.

Discuss Your Project Back to Services

Enterprise Blockchain Development

Sphere 10 engineers blockchain systems for organisations that need a shared, verifiable record across operational boundaries. We design the ledger rules, application interfaces and operating model together, from enterprise applications on an existing network to purpose-built distributed ledgers. Use cases include shared asset registers, traceable business events, coordinated settlement records and verifiable exchanges between organisations with different responsibilities.

The architecture starts with who can propose a change, who validates it and what participants must be able to prove. Those answers determine identity, permissions, transaction processing and data visibility. Our .NET engineering connects the ledger to enterprise APIs, operational tools and relational reporting. Sphere10 Framework contributes reusable cryptographic, serialisation and chain-management building blocks, while the product implements the protocol and governance required by its actual participants. We deliver the whole system with explicit recovery behaviour, measurable acceptance cases and clear ownership of ongoing network operation.

💡 Define the Trust Boundary — Identify the organisations, the records they exchange and the evidence each one needs. The ledger design should follow those business relationships.

Specify Participants, Authority and Finality

We define who writes records, who validates them and which participants can read the resulting information. Membership changes, privileged actions and dispute handling are explicit parts of the model. Confidential business information and shared evidence can have different storage and access requirements, so the data design separates them deliberately.

We select a ledger architecture from the participation and execution model. Hyperledger Fabric provides organisation identities, endorsement policies, channels and private-data collections. Besu supplies a permissioned EVM network with QBFT validator consensus when Solidity compatibility is central. Polkadot SDK/Substrate with Rust FRAME pallets supports a purpose-built runtime. The specification maps membership, deterministic validation, transaction ordering and business completion to the selected network's actual mechanisms.

Document participant roles, key authority and membership procedures.
Define transaction validity, ordering and the accepted completion condition.
Map private information, shared records and externally verifiable evidence.

Compose Ledger and Enterprise Application Layers

Sphere10 Framework consensus components expose reversible operations, linear chains and candidate-branch management as reusable .NET foundations. We combine appropriate mechanisms with the validation, persistence, networking and selection rules the protocol requires. Binary formats, signatures and integrity structures receive explicit specifications and compatibility fixtures.

C# application services connect ledger operations to enterprise identity, approvals and existing records. Nethereum handles EVM calls and receipts for a suitable Besu or public EVM deployment. A Fabric integration can use a small service built on the official Go, Node or Java Gateway API and expose a documented contract to .NET. BlockchainSQL Server provides a Bitcoin-to-SQL/explorer reference for ingestion, checkpointing and operational read models around authoritative chain records.

Separate protocol rules from node transport and enterprise application policy.
Retain transaction and chain context in queryable operational records.
Expose explicit APIs for permitted submission, lookup and administration.

Demonstrate Behaviour Across Faults and Changes

Acceptance covers conflicting operations, repeated submissions, incompatible messages and node interruption. Where branch changes are possible, we demonstrate rollback and reapplication of affected state, then reconcile derived views. Tests use the agreed network topology, workload and participant assumptions so their results describe the system being delivered.

A Fabric deployment exercises endorsement failure, certificate rotation and commit validation status. A Besu QBFT deployment tests validator availability and membership changes against its quorum requirements. FRAME work includes storage migrations, runtime version compatibility and deterministic pallet tests. Across these choices we verify retries, interrupted submissions and application projections, with diagnostics that distinguish a pending transaction, rejected operation, stalled network and stale enterprise read model.

Test restart and replay without duplicating accepted business operations.
Verify state consistency after the defined failure and recovery scenarios.
Measure processing and query behaviour with representative transaction data.

Deliver the Protocol and Its Operating Model

You receive protocol and application source, deployment configuration, interface definitions and acceptance fixtures. The operating runbook identifies node responsibilities, key custody, monitoring, backup and recovery authority. We document how new participants and versions enter the system and which decisions require coordination between organisations.

Delivery includes chaincode or runtime/contract source as applicable, network configuration, application APIs and acceptance fixtures. The runbook defines node roles, participant onboarding, key custody, validator or endorsement governance and backup/recovery authority. Staged rollout and independent assessment can be release milestones. Ongoing network changes then follow a named coordination and operating model tied to the exact software, identity and protocol baseline being deployed.

Provide reproducible node and application builds with dependency inventories.
Demonstrate participant onboarding, monitoring and permitted recovery actions.
Retain protocol specifications and compatibility tests for subsequent changes.

Technologies & Integration

Sphere10 Consensus — Reusable .NET reversible-operation and chain-management foundations for a deliberately specified custom ledger protocol.
Nethereum — C# EVM calls, transactions and events integrated with ASP.NET Core business services and relational reporting.
Hyperledger Fabric — Organisation/endorsement-based ledger integration through official Go, Node or Java Gateway clients and a defined .NET service boundary.
Besu / Polkadot SDK — QBFT EVM validator networks or Rust/FRAME custom runtimes selected from the participation and execution requirements.

Discuss Your Project Back to Services

UI/UX Design

Sphere 10 designs interfaces that make complex software and blockchain operations understandable. We turn wallet connections, signatures, approvals and transaction results into coherent customer journeys, with equal attention to administration and support. The design covers what people need to know, which decisions they can make and how the application explains progress or failure. It connects visual presentation to the behaviour the engineering team will implement.

We work from real tasks and realistic information: long addresses, unfamiliar assets, missing records, rejected signatures and delayed results. Interactive prototypes make those situations reviewable before the full build. Our .NET and blockchain engineering gives the design a concrete technical foundation, including API contracts, authoritative state and operational workflows. BlockchainSQL Server 's explorer and scanning application provide relevant product references for presenting chain records and processing activity. The result is an implementable interface specification with useful components, clear states and testable user outcomes.

💡 Design the Decision Behind the Button — A user should know what will happen, what authority they are granting and how completion will be recognised before committing a consequential action.

Map the User Journey and Its Decisions

We identify the customer and operator tasks the product must support, then map the information and choices required at each step. A message signature, token approval and asset transfer have different consequences. Their interfaces need accurate language, visible context and an appropriate confirmation step.

We model ordinary business tasks and specialist flows such as a wallet signature or token approval using real records and consequences. Figma journey maps and prototypes expose navigation, account switching, status hierarchy and recovery paths before implementation. Long identifiers, empty states and unavailable data are designed alongside populated screens so the product communicates clearly under the conditions its customers and operators will actually encounter.

Document primary tasks, user roles and permission-dependent actions.
Explain amounts, addresses, network identity and approval scope clearly.
Define empty, loading, pending, successful and rejected states.

Prototype With the Real Application Model

We build wireframes and interactive prototypes for the agreed workflows, supported by a reusable component language. Typography, spacing, controls and feedback work together across the required screen sizes. Component states describe practical behaviour such as validation, disabled actions, copying an identifier and viewing transaction details.

The design system follows the chosen host: Fluent patterns for a Windows product, Material 3 for Android, Apple Human Interface Guidelines for Apple applications, and reusable web components for Blazor or React. Component states map to C# API models and server-enforced permissions. BlockchainSQL Server and Sphere10 Framework application experience inform progress, record inspection and operator controls, while each product receives its own task-specific interaction model.

Create reusable components for records, amounts, status and transaction review.
Specify responsive behaviour with real long and missing content.
Map prototype actions to application operations and resulting states.

Validate Understanding, Accessibility and Recovery

We review the prototype using complete tasks: choose the correct account, inspect a record, authorise an operation and determine its outcome. Long addresses, stale data, unavailable networks and conflicting account state are part of that review. The design should help users recognise the situation and select a useful next action.

For web delivery we check relevant WCAG 2.2 criteria through keyboard navigation, visible focus, labels, contrast, text enlargement and error recovery. Native testing uses the platform's accessibility tools, including VoiceOver or TalkBack where applicable. Playwright retains repeatable browser workflow evidence; manual task review checks meaning and usability. A working .NET-backed slice validates uncertain permissions or asynchronous state transitions behind the prototype.

Test error messages for a clear explanation and corrective action.
Distinguish wallet authorisation, submitted transactions and accepted results.
Check narrow layouts, keyboard access and important assistive-technology paths.

Hand Over a Design the Build Can Follow

The delivery includes journey maps, component states, content and interaction specifications with acceptance examples. We identify reusable assets and record the relationship between prototype screens and implemented features. Developers can see how navigation, validation and asynchronous work should behave, including the states that are easy to omit from a visual mock-up.

Handover supplies Figma components, design tokens, content rules, interaction states and acceptance examples tied to the implemented toolkit. Responsive layouts are reviewed with real copy and records, including validation and pending/error states. We can continue into Blazor, MAUI, Windows or another selected implementation and compare the working result with the accepted journey. Future features then extend a coherent component vocabulary and observable completion criteria.

Provide source design assets and documented component/interaction states.
Retain realistic task scenarios for implementation acceptance.
Review the delivered interface at the agreed desktop and mobile sizes.

Technologies & Integration

Figma — Journey maps, interactive prototypes, reusable components and design-token handover tied to the selected product workflow.
Blazor — Implemented web components whose states and permitted actions follow explicit C# service contracts.
WCAG Guidance — Relevant WCAG 2.2 criteria translated into keyboard, focus, contrast, text and error-recovery checks.
Playwright — Repeatable browser task evidence across the agreed engines, alongside manual accessibility and usability review.

Discuss Your Project Back to Services

Smart Contract Development

Sphere 10 designs and implements smart contracts for tokens, digital assets, DeFi, governance and business settlement. We build the on-chain rules together with wallets, applications and operational controls, choosing Ethereum-compatible contracts or Polkadot runtime engineering for the actual requirement. Our article What are Smart Contracts? explains the execution model; this offering covers the specific interfaces, permissions, accounting and deployment work needed to turn that model into an operable product.

Delivery spans Solidity, Polkadot SDK Rust and C# integration: token issuance and vesting, escrow and staking, vaults and AMMs, signed authorisations, smart accounts and upgradeable systems. We distinguish a published interface from its implementation and a runtime pallet from a deployed contract. Every release identifies its target network, compiler, authority model and acceptance evidence, with transaction tracking, administration and recovery procedures included rather than left to the surrounding application team.

💡 Start With One Exact Transaction — Choose a real movement of value or authority. We specify its preconditions, permitted state changes and observable completion before building the contract.

Ethereum Tokens, Vaults and Settlement

We implement ERC-20 fungible assets, ERC-721 unique assets and ERC-1155 multi-token collections, with explicit minting, burning, approvals and transfer policy. ERC-4626 vaults add deposit/share/redemption interfaces, backed by specified custody, fees, rounding and withdrawal liquidity. Asset delivery also covers vesting and escrow, metadata and marketplace settlement; ERC-2981 supplies royalty information whose payment depends on the marketplace. We compose OpenZeppelin components with the required business rules. Existing ERC-777 operator/hook contracts receive compatibility and reentrancy review as a legacy estate, while new token designs select the interfaces their users actually need.

Permissioned assets: implement ERC-3643 identity registries, transfer checks and agent operations around the agreed compliance rules; integrate existing ERC-1400 -family partitions and controller interfaces where an estate already uses them.
Specialised NFTs: apply ERC-4907 expiring user rights for rentals, ERC-5192 lock state for non-transferable credentials, or review-stage ERC-6551 token-bound accounts where the application needs asset-owned execution.
Vaults, staking and rewards: implement share conversion, reward accrual, vesting and redemption; test precision, donation effects, withdrawal queues and solvency across economic boundary cases.
DeFi integrations: build Uniswap v3 liquidity-position workflows, v4 pool hooks and Aave supply/borrow/repay adapters with explicit slippage, allowance, collateral and liquidation behaviour.

Wallets, Governance and Upgrade Architecture

Signed workflows use EIP-712 structured messages with application-defined nonces, deadlines and domain checks; ERC-2612 permit adds signed ERC-20 approvals, while ERC-1271 supports contract-wallet signature validation. Smart-account delivery can include ERC-4337 UserOperations, bundler integration and paymaster policies, and EIP-7702 delegation on networks that support it. We test the selected wallet and EntryPoint deployment together. Governance, recovery and spending permissions are designed as part of the authority model, not inferred from a connected wallet address.

Governance and treasuries: compose OpenZeppelin Governor and TimelockController proposal execution with Safe owner thresholds, reviewed modules, signer succession and emergency authority.
ERC-1967 / UUPS or transparent proxies: initialise correctly, authorise upgrades and validate storage compatibility; immutable deployment remains an explicit design choice.
ERC-2535 diamonds: use facets and selector routing when modular upgrade requirements justify the additional storage and authority complexity.
External evidence: integrate Chainlink Data Feeds with freshness checks, VRF with request/fulfilment state, and CCIP with authenticated cross-chain messages, replay protection and per-lane finality rules.

Polkadot, Substrate and JAM

Polkadot work separates deployed smart contracts from the chain runtime. On Polkadot Hub and compatible targets, we verify the actual pallet-revive backend and toolchain: Solidity can target PolkaVM through resolc, with execution and deployment differences tested explicitly. Custom Substrate/FRAME work builds Rust runtime pallets, storage, dispatchable calls and migrations. Existing ink! estates receive maintenance and migration assessment: its maintainers report active development stopped in January 2026. JAM prototype work targets an identified Gray Paper revision, including service boundaries, refinement and accumulation, with runtime and interoperability assumptions recorded for each experiment.

Contract execution: verify target-chain ABI/RPC support, compiler output, factory deployment, gas/weight limits and storage deposits; PVM is not EVM bytecode.
Runtime engineering: configure or build FRAME pallets for assets, permissions and governance, with origin checks, benchmarks and versioned storage migration.
Legacy contracts: identify pallet-contracts versus Revive targets before changing ink! code, dependencies, deployment tooling or wallet integrations.
JAM readiness: build service prototypes around refine/accumulate entry points, validate assumptions against the current Gray Paper and record the path from experiment to any future production target.

Test, Integrate and Hand Over

Foundry and Hardhat provide the reproducible unit, fuzz, invariant and integration test harness; Slither adds static-analysis findings for engineering review. We challenge supply, custody and settlement rules across adversarial action sequences. C# services use Nethereum for ABI bindings, signing boundaries, receipts and events, with ASP.NET Core exposing authorised operations. Submission, inclusion and business completion remain distinct, and replayable read models recover from node failures and reorganisations. Our Bitcoin-focused BlockchainSQL work informs that indexing discipline. Delivery includes reproducible builds, deployments, authority registers and operational handover, with specialist findings tracked through remediation and retesting.

Test unauthorised callers, reentrancy, external-call failure, signature replay and economic edge cases; measure execution against target-chain limits.
Rehearse deployments and upgrades using pinned compiler/dependency versions, exact bytecode and environment-specific configuration.
Integrate wallet rejection, replacement transactions, duplicate events and reorganisation recovery without duplicating business actions.
Hand over source, ABIs, tests, deployment evidence, monitoring, key succession and incident runbooks with named operational ownership.

Technologies & Integration

Solidity and OpenZeppelin — Implement token, governance and proxy components against the selected EVM target; review custom business rules and authority boundaries.
Ethereum interface standards — Select ERC-20/721/1155, ERC-4626, signature and smart-account interfaces for the actual asset and wallet workflows.
Polkadot SDK, FRAME and Revive — Build Rust runtime pallets or deploy target-compatible contracts with explicit compiler, execution and migration evidence.
Foundry and Nethereum — Connect adversarial contract tests to versioned C# ABI clients, receipt processing and recoverable event projections.
ASP.NET Core and JAM research — Deliver authorised operator APIs; assess prospective JAM services separately from existing-chain contract deployment.

Discuss Your Project Back to Services

Blockchain Consulting

Sphere 10 helps organisations turn a blockchain proposal into an implementable decision. We begin with the parties, assets and disagreements the system must handle, then establish whether a shared ledger changes the trust model in a useful way. The review covers transaction authority, participant identity, settlement, privacy and the surrounding business systems. A credible recommendation connects those requirements to a concrete architecture, operating model and cost profile that decision-makers can examine.

We combine protocol-level reasoning with practical .NET application and data engineering. That lets us assess the complete workflow, including wallets, node access, contract administration, event processing and the records your organisation must retain. Our Bitcoin-focused BlockchainSQL product provides an inspectable example of chain ingestion and SQL-facing analysis. We use relevant implementation evidence to shape the proposal, then produce the decisions, prototypes and delivery boundaries needed to move confidently from assessment into a defined build.

💡 Name the Shared Trust Problem — Identify the parties that cannot rely on one operator, the facts they must agree on, and the rights each participant retains.

Test the Ledger Proposition Against Real Work

We trace a real transaction from its initiating party to settlement, then map the required authority and verification to a concrete platform. Ethereum or an EVM rollup can provide public settlement; Fabric can coordinate identified organisations through endorsement policies; a Polkadot SDK/FRAME runtime can enforce application-specific state transitions. We compare those designs with a conventional .NET application and signed audit trail using the same privacy, governance and operational requirements. The decision records what should trigger reconsideration as participants or workloads change.

Document participants, disputed facts, asset ownership and settlement responsibilities.
Separate commercially sensitive data from information suitable for a shared ledger.
Identify external facts that still depend on an oracle or trusted authority.
Compare the operating burden with a conventional database-backed implementation.

Choose the Network and Governance Together

Network choice includes its actual control model. Arbitrum Nitro and OP Stack designs require sequencer, settlement and withdrawal-path analysis; Besu QBFT requires validator/quorum planning; Fabric requires organisation identities, channels and endorsement rules. Polkadot SDK work separates runtime pallets, governance and XCM configuration from an application contract deployed to a selected VM. We assess administrative keys, upgrades, node access, fees and disruption behaviour against the intended transaction pattern and the organisations responsible for operating it.

Record validator, sequencer or consortium responsibilities and external dependencies.
Define upgrade approvals, emergency powers and participant onboarding procedures.
Measure representative transaction cost and latency under stated test conditions.
Specify data retention, identity mapping and off-chain confidentiality requirements.

Prototype the Hard Integration Boundary

The prototype proves the hardest boundary with its real stack: a C#/Nethereum EVM operation, a Go/Node/Java Fabric Gateway adapter exposed to .NET, a FRAME runtime call or a Bitcoin Core import. We include rejected submission, uncertain response and restart/reconciliation cases. BlockchainSQL Server supplies a Bitcoin-to-SQL reference for source identity, checkpointing and inspectable projections. The result measures the selected integration and updates delivery scope from observed behaviour.

Demonstrate one complete transaction, including rejection and recovery paths.
Retain network, contract and source-record identity in application data.
Verify restart, duplicate-event and delayed-confirmation behaviour against the design.
Use measured prototype findings to update scope, estimates and technical decisions.

Turn Findings Into a Delivery and Ownership Plan

You receive an architecture and decision record with selected platforms, contract/runtime standards, custody arrangements and explicit unresolved assumptions. The delivery backlog names node configuration, C# APIs, data migrations, signing flows and operator tooling alongside acceptance evidence. We assign hosting, monitoring, upgrades and incident authority, with specialist review inputs where required. The package can progress into an implementation or provide another engineering team with reproducible prototype source, measured findings and a clear operating model.

Deliver a reasoned network choice with alternatives and decision triggers.
Define interfaces, migration needs, operational roles and release responsibilities.
Set acceptance evidence for performance, reconciliation and business-rule correctness.
Hand over prototype source, test results and a prioritised implementation roadmap.

Technologies & Integration

Ethereum / EVM Rollups — Public settlement and L2 architecture assessment covering sequencer, finality, fee and withdrawal assumptions.
Hyperledger Fabric — Organisation identity, channel/private-data boundaries and endorsement/commit workflows for permissioned coordination.
Bitcoin RPC — Bitcoin node/import and settlement-observation boundaries, informed by the Bitcoin-focused BlockchainSQL Server product.
Nethereum — Executable C# prototypes for EVM calls, receipts, signing integration and replayable event processing.
ASP.NET Core — Business-facing APIs, permission checks and adapters around the selected ledger and enterprise systems.

Discuss Your Project Back to Services

Token Development

Sphere 10 builds tokens with a defined economic purpose, an explicit authority model and the application workflows needed to use them. We develop fungible assets, membership rights, allocation instruments and redemption mechanisms around the actual obligations your organisation intends to represent. The design establishes what a token means, who can issue or retire it, how transfers affect those obligations and which records remain in the business system alongside the contract.

A token launch also needs reliable allocation, administration and reconciliation. We deliver the selected contract or token-program configuration, C# services, operator interfaces and release procedures as one coherent system. ERC-20 provides a recognised EVM interface; Solana token programs and Polkadot assets provide different native models. Supply policy, custody, restrictions and recovery remain deliberate product decisions. We turn those decisions into executable rules and acceptance scenarios, so your team can explain balances, operate privileged functions and maintain the implementation after initial deployment.

💡 Define the Unit of Value — Specify what one token represents, its precision, the supply rules and the business obligation created when it is issued or redeemed.

Design Supply and Permission Boundaries

For Ethereum/EVM assets we implement ERC-20 transfers and allowances with selected OpenZeppelin extensions such as ERC-2612 permit, voting checkpoints, caps or pausing. VestingWallet can express timed allocations; a regulated transfer model can use ERC-3643 identity and transfer-policy components when the specification requires them. Solana SPL Token/Token-2022 and Polkadot assets use their own mint or runtime authority models. In every case we define issuance, burn, treasury, freeze and upgrade powers, integer precision and redemption rules before deployment.

Define initial distribution, maximum supply and permitted supply-changing operations.
Map each privileged action to a role and its succession procedure.
Specify allowance, delegation and transfer restrictions using concrete user scenarios.
Record rounding, minimum units and redemption calculations without floating-point ambiguity.

Build the Operational Ledger Around the Contract

C# services link allocations, approvals, beneficiaries and business obligations to authoritative token operations. Nethereum handles EVM calls/events; Solana integration uses its token program and account model; a Polkadot asset integration uses the target runtime's metadata and calls. The system distinguishes a requested issuance from a confirmed balance and fulfilled obligation, retaining network, mint/contract/asset identifier and source transaction. Rebuildable projections and reconciliation reports explain outstanding allocations and redemptions; BlockchainSQL provides a Bitcoin-focused reference for that projection discipline.

Link issuance requests to approvals, beneficiaries and immutable transaction references.
Track pending, confirmed, rejected and replaced transactions as separate states.
Produce allocation, transfer, redemption and outstanding-liability reconciliation views.
Make restart and event replay safe through explicit processing identifiers.

Prove Token Invariants and Integration Behaviour

Acceptance tests conservation, role enforcement, allowance changes, boundary values and repeated redemption across contract and application layers. For Token-2022 we select extensions before mint creation and test their compatibility with each other and the intended wallets; transfer fees, hooks and non-transferability alter downstream behaviour. Polkadot asset tests exercise issuer, admin and freezer authority as configured. Derived totals are checked against chain state after replay, rejected signatures and interrupted ingestion, with exact integer values retained throughout.

Assert the supply equation after mint, transfer, burn and redemption sequences.
Exercise unauthorised minting, duplicate requests and exhausted allocation limits.
Verify displayed precision and totals against exact integer contract values.
Rehearse deployment, role transfer and the agreed contract administration journey.

Hand Over a Token Your Team Can Operate

The handover records deployed bytecode/program identity, mint or asset configuration, authorities, opening allocations and the exact standards/extensions implemented. Source, ABI or runtime interface definitions, tests and deployment scripts accompany treasury approvals, key succession, monitoring and reconciliation procedures. EVM upgrades receive storage-layout checks; Solana authority changes and runtime asset administration follow their own tested mechanisms. The release plan can include independent review and specialist legal inputs tied to the actual token obligations and administrative powers.

Record initial balances, role assignments, configuration and deployed bytecode identity.
Document treasury approvals, key succession and exceptional operational procedures.
Deliver reconciled opening reports and repeatable checks for ongoing operations.
Agree ownership of support, monitoring, dependencies and future supply-policy changes.

Technologies & Integration

ERC-20 — Fungible EVM balances, transfers and allowances with exact integer accounting and explicit supply authority.
OpenZeppelin ERC20 — Selected permit, votes, cap or pause components configured against the token's actual issuance and administration rules.
OpenZeppelin Access Control — Mint, treasury, pause and upgrade roles with tested ownership transfer and succession procedures.
Solana Token-2022 — Mint/account extensions selected before creation and tested for mutual and wallet compatibility.
Polkadot Assets — Runtime-managed fungible asset classes with explicit owner/issuer/admin/freezer permissions and application integration.

Discuss Your Project Back to Services

Blockchain Integrations

Sphere 10 connects blockchain networks to the applications, financial records and operational workflows that use their data. We build transaction submission, payment observation, contract event processing, node imports and business-facing APIs with explicit boundaries between the chain and the organisation. The integration identifies which system owns each fact, what confirmation means for the workflow and how the application behaves while network observations are incomplete or change.

Our implementation treats recovery as a normal operating requirement. C# services retain checkpoints, source identifiers and processing outcomes so imports can resume and messages can be handled again without duplicating a business effect. We develop the connector, persistence model, reconciliation and operator controls together. BlockchainSQL is a concrete reference for Bitcoin data ingestion and SQL-facing projections; EVM integrations use chain-appropriate clients such as Nethereum and preserve their own contract and network semantics throughout the application.

💡 Define the Completion Boundary — Agree when a chain observation is sufficient to update the business record, and how that decision is reversed or reconciled if the observation changes.

Model the Boundary Between Two Systems

We specify the exact chain interface and the fact it supplies. Ethereum integration uses ABI encoding, JSON-RPC calls, receipts and logs; Bitcoin Core supplies transaction/block and UTXO observations; Polkadot uses runtime metadata, SCALE-encoded calls and storage; Solana uses program accounts, transaction signatures and commitment levels. Each adapter retains network, account, units and business correlation identity. Submission, inclusion, finality and application completion become explicit states, with signing authority and permitted operations defined at that boundary.

Define the authoritative owner and identifier for each exchanged business fact.
Separate submission, inclusion, confirmation and application completion states.
Specify decimal precision, address validation and network selection rules.
Document authentication, signing custody and permitted connector operations.

Implement Durable Ingestion and Reconciliation

Nethereum block/log processors support checkpointed EVM ingestion; we commit stable event identities and processing outcomes with the local business update where appropriate. Bitcoin reads retain block hashes as well as heights, while Polkadot decoders follow the selected runtime metadata and version. An outbox records outbound intent before external work. Bounded retries, cursor persistence and chain-specific rewind/reconciliation rules let the connector resume without duplicating an allocation or payment effect, with external waits outside long database transactions.

Persist checkpoints, block hashes, message identities and processing outcomes.
Reconcile node observations with existing balances, obligations and ledger projections.
Apply bounded retries with inspectable failures and operator-controlled recovery.
Keep external network waits outside long-running local database transactions.

flowchart TD
  W["Wallet or multisig"] -->|Sign| C["Contract or runtime call"]
  C --> N["EVM or Polkadot node"]
  N --> I["Event indexer"]
  I --> F{"Confirmation policy met?"}
  F -->|Wait| I
  F -->|Yes| B["C# reconciliation service"]
  B --> D["SQL business records"]
  N -. Reorganisation .-> I
  classDef default fill:#eaf2ff,stroke:#2f77cb,color:#17365d,stroke-width:1.5px

Connect Chain Data to Useful Application Interfaces

ASP.NET Core exposes application-authorised commands, payment status and reconciliation queries over the connector's durable state. BlockchainSQL Server illustrates Bitcoin parsing, transformation and an inspectable SQL-facing model. Solana account/event projections and Polkadot storage/extrinsic views receive their own source identifiers and confirmation policy. XCM or another cross-chain integration additionally tracks message routing, execution and acknowledgement outcomes. OpenTelemetry traces and metrics connect the business operation to node calls and processing checkpoints for investigation.

Expose clear pending, confirmed, disputed and failed processing statuses.
Retain source references that let an operator investigate an individual record.
Version connector contracts and stored payload formats independently of the UI.
Provide reconciliation reports that identify missing, repeated or inconsistent observations.

Accept Recovery as Part of the Delivered Feature

Acceptance stops nodes, interrupts imports and repeats observations against a recorded source range. We exercise EVM reorganisations, selected Bitcoin confirmation/rewind policy, Solana commitment progression or Polkadot runtime changes as applicable. Transaction replacement, expired submissions and lost responses are reconciled before another action is issued. Delivery includes adapters, schema/version contracts, fixtures, monitoring and recovery runbooks; operators can explain totals after replay and trace a failed operation to its authoritative chain evidence.

Interrupt processing between receipt, local commit and external acknowledgement.
Demonstrate restart and replay using a recorded source range.
Verify duplicate handling and reorganisation policy against business expectations.
Hand over deployment configuration, operational dashboards and recovery runbooks.

Technologies & Integration

Nethereum Log Processing — Checkpointed C# EVM block/log processing with stable event identity, replay and application reconciliation.
Ethereum JSON-RPC — ABI calls, transaction submission, receipts and log queries with explicit network and confirmation semantics.
Bitcoin RPC — Node observations and source block identity around Bitcoin import, payment state and BlockchainSQL-style relational projections.
Polkadot / Solana APIs — Runtime-metadata/SCALE interfaces or Solana account/transaction RPCs, each with its own decoding and completion policy.
OpenTelemetry — .NET traces, metrics and logs correlating business operations with RPC calls, checkpoints and recoverable connector failures.

Discuss Your Project Back to Services

Cryptographic Analysis

Sphere 10 analyses cryptographic designs at the point where algorithms, data formats, keys and application behaviour meet. We review signing, authenticated encryption, hashing, key derivation and integrity constructions against a defined threat model and the actual protocol using them. The work covers both new designs and existing systems that need interoperability, migration or a clear explanation of their cryptographic assumptions before further development.

Our approach combines mathematical and protocol reasoning with executable C# tests and concrete implementation inspection. We identify exactly which bytes are authenticated, how keys are created and stored, which context prevents messages being reused incorrectly and what the recipient rejects. We use established primitives and published test vectors, then examine how they are composed in your system. You receive reproducible findings, scoped implementation corrections and verification artefacts that connect each conclusion to an observable behaviour or explicit assumption.

💡 Specify What the Adversary Can Do — State the attacker’s access, chosen inputs, captured messages and key exposure assumptions before deciding what the construction must protect.

Trace the Construction From Input to Verification

We specify the exact bytes passing through canonicalisation, encoding, hashing, signatures or authenticated encryption. For a blockchain signature this includes curve, digest, chain/domain context and signature encoding; for a service message it includes field boundaries, protocol version and replay state. SHA-256, SHA-3 and Keccak-based formats are selected according to the protocol's actual definition. Malformed lengths, ambiguous encodings and altered recipient/context fields become executable rejection cases, so verification is tested against the construction the application really uses.

Document the exact authenticated bytes, encodings and field boundaries.
Identify trust assumptions, attacker-controlled inputs and verification decision points.
Check replay protection, context binding and protocol-version separation.
Inspect malformed-input handling and the application’s response to verification failure.

Review Keys, Randomness and Established Primitives

The review covers AES-GCM nonce/tag handling, HKDF extract-and-expand context, and signature schemes such as Ed25519 or protocol-required ECDSA/secp256k1. We inspect key generation, custody, rotation, retirement and library configuration together. In Sphere10 .NET applications, established Framework cryptographic abstractions provide the integration boundary, with compatible vetted implementations selected for the required scheme. The application owns key purpose, authenticated context and permissions, while implementation review checks errors and secret lifetimes at each call.

Evaluate key generation, entropy sources and deterministic derivation requirements.
Check nonce uniqueness rules and rejection of invalid authentication tags.
Separate signing, encryption and derivation keys according to their intended uses.
Document key custody, rotation, recovery and secure retirement responsibilities.

Build Interoperability and Adversarial Test Evidence

Known-answer vectors and cross-implementation fixtures verify messages versus digests, byte order, signature representation and invalid inputs. Merkle proof tests fix leaf encoding, node order and tree shape. For post-quantum migration work we assess ML-KEM key establishment under FIPS 203, ML-DSA signatures under FIPS 204 or SLH-DSA signatures under FIPS 205, checking implementation availability, parameter sets and protocol compatibility. Timing or other side-channel assessment receives a defined measurement scope tied to the threat model.

Reproduce published vectors before testing project-specific compositions.
Compare results across the real client, server and supported language runtimes.
Mutate messages, tags, signatures and proof nodes to test rejection behaviour.
Retain minimal test cases for every confirmed discrepancy or ambiguity.

Deliver Findings That Can Be Implemented and Closed

Each finding records the affected construction, prerequisites, reproduced behaviour and correction with retest evidence. Migration plans cover key/format versions, stored ciphertext or signatures, peer compatibility and transition rules; cryptographic agility is implemented as explicit protocol negotiation and version policy. Handover contains the construction specification, vectors, test harness and key-management operating notes. Standard conformance and any required validated-module deployment are assessed for the exact implementation and environment within the agreed scope.

Provide reproducible cases and source-level remediation guidance for confirmed issues.
Define compatibility and data-migration steps before replacing a cryptographic format.
Retest corrected behaviour against the original adversarial and interoperability cases.
Hand over the construction specification, vectors and key-management operating notes.

Technologies & Integration

.NET Cryptography — Review vetted implementations and Sphere10 Framework integration boundaries alongside key purpose, format and application permissions.
AES-GCM — Authenticated-encryption nonce construction, associated data, tag verification and failure handling tested against the exact protocol.
HKDF — Extract-and-expand key derivation with explicit input material, salt, purpose/context and published interoperability vectors.
EdDSA — Ed25519/Ed448 scheme and encoding checks using published vectors, with protocol-specific signature alternatives evaluated explicitly.

Discuss Your Project Back to Services