Digital Asset Systems|Digital Asset Platforms|Ownership and Entitlements
An NFT is useful when holding it gives someone something definite, such as a membership, a certificate, a collectable or a transferable entitlement. Sphere 10 builds the whole product around that asset: the contract, the customer interface, the .NET backend and the administration tools your team uses after launch.
What we build
Define the asset and its lifecycle. We agree who can issue an item, what a holder receives, how it can move and whether it can expire or be revoked, then decide which rules the contract enforces and which stay in your application.
Build on recognised standards. On Ethereum and compatible networks we use ERC-721 for individual items and ERC-1155 for editions. Solana is assessed against the wallets and marketplaces you need.
Connect ownership to your product. Wallet connection, transaction review and confirmation status are part of the customer journey, and confirmed ownership drives the access or benefit the holder is entitled to.
Keep content available. Metadata and media stored on IPFS get a retention plan and a named owner, so the content the asset points to stays online.
Wallet actions reach the contract, while indexed events connect confirmed ownership to application entitlements.
What you receive
Contract source, deployment configuration and a record of deployed addresses.
The application code and administration tools for issuance, asset lookup and support investigation.
A handover that names keys, administrative permissions and metadata hosting.
How we engage
Design starts from the entitlement: what holding the asset permits and which system enforces it. Acceptance follows one asset through issue, inspection, transfer and use in the real application on the agreed test network, with your selected wallet and marketplace integrations. An independent contract review can be set as a release milestone.
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.
First Working Release|First Commercial Release|End-to-End .NET Delivery
You have a blockchain product idea and need a first release that people can use. Sphere 10 delivers the customer interface, application services, contract or node integration, data storage and deployment as one working product, shaped around a single business journey such as issuing a credential, transferring an asset or reconciling a payment.
What we build
Choose the first journey. We define one complete customer outcome, the operator actions that support it and the evidence that it worked.
Build every layer. Our usual foundation is C# and ASP.NET Core with a Blazor or React web interface, a mobile client where one is required, and SQL Server or PostgreSQL for your application records.
Include the operating side. Sign-in, permissions, administration, diagnostics and recovery tools are part of the first release, so your staff can support real users.
Make status clear. A customer can tell whether an action was requested, is still processing, completed or was rejected, and support staff can find its history.
The first customer outcome crosses interface, application, chain and operational data boundaries.
What you receive
Application source, database migrations, configuration and deployment instructions.
Contract source and chain addresses where the product uses them.
Acceptance records and operator procedures for diagnosis and recovery.
A prioritised backlog for the next release, grounded in the accepted build.
How we engage
Project Design selects the first journey, the technology and measurable acceptance examples before the build scope is committed. We then test the complete journey with representative records, including a rejected action, a lost response and a service restart with work outstanding. Further QA or continuing execution after handover is scoped explicitly. Our BlockchainSQL Server product is a working reference for this kind of end-to-end engineering.
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.
Some project decisions wait on one technical question, such as whether a node can supply the history you need, whether an indexer recovers after a fork or whether a processing path can carry the intended workload. Sphere 10 builds a focused proof of concept that answers that question with evidence you can inspect and rerun.
What we do
Write the decision first. We state the hypothesis, the representative inputs and the pass or fail threshold before the harness is built, so the result can change the plan.
Test against the real boundary. The experiment uses the actual node, provider, protocol or dataset that could overturn the design, kept small enough to give a clear answer.
Measure the weak cases. Malformed records, duplicates, incomplete history and a restart during processing are exercised alongside the normal path.
Report what was and was not shown. Observed behaviour is separated from assumptions that remain untested, and correctness evidence is separated from speed or resource measurements.
A defined technical question drives a reproducible harness, observed results and an explicit project decision.
What you receive
A runnable test harness with source, input data and the commands to rerun it.
Recorded results with the conditions they were measured under.
A concise decision record recommending that you proceed, revise the design or stop.
Build and acceptance requirements drawn from what the experiment confirmed.
How we engage
A proof of concept is bounded by its question. We agree the question and its threshold with you, run the experiment and present the findings with the remaining risks. Useful code can be kept for the build, and your team can rerun the experiment when a provider, library or workload changes. Operational hardening and release acceptance belong to the production project and are scoped there.
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.
When several organisations need to rely on the same record across their operational boundaries, a shared ledger gives each party a verifiable account of what happened. Sphere 10 engineers these systems for shared asset registers, traceable business events and settlement records between organisations, from applications on an existing network to purpose-built ledgers.
What we build
Define the trust boundary. We establish which organisations write records, who validates them, who can read them and what each party must be able to prove.
Select the ledger to fit. Hyperledger Fabric, a permissioned Ethereum-compatible network on Besu or a purpose-built Polkadot SDK chain is chosen from how your participants work together.
Connect it to your business systems. .NET services link the ledger to your identity, approvals, existing records and relational reporting.
Separate private from shared. Confidential business information and shared evidence are stored and accessed under different rules.
Participant authority and validated operations connect a shared ledger to enterprise services and reconciled query views.
What you receive
Ledger and application source, network configuration and interface definitions.
Acceptance tests covering conflicting operations, repeated submissions and node interruption.
A runbook naming node roles, participant onboarding, key custody, monitoring, backup and recovery authority.
Documentation of how new participants and new versions enter the network.
How we engage
The design work settles governance as well as technology, because membership changes, privileged actions and dispute handling are explicit parts of the model and some decisions need coordination between organisations. Acceptance runs on the agreed network layout and workload, including recovery from the failures the participants have agreed to handle. Staged rollout and independent assessment can be release milestones.
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.
Clear Transaction Journeys|Interfaces Built to Ship
Blockchain actions are consequential, so people need to understand what will happen and what authority they are granting before they commit. Sphere 10 designs interfaces that turn wallet connections, signatures, approvals and transaction results into clear journeys for customers, administrators and support staff.
What we do
Map the tasks and decisions. We identify what customers and operators need to do and what they must know at each step. A message signature, a token approval and an asset transfer each get accurate wording and a suitable confirmation.
Prototype with realistic content. Interactive Figma prototypes use long addresses, unfamiliar assets, missing records and delayed results, so the difficult cases can be reviewed before the build.
Design waiting and failure. Empty, loading, pending, successful and rejected states tell the user what has happened, what remains and who can act.
Check accessibility. Web designs are checked against the relevant WCAG 2.2 criteria for keyboard use, visible focus, contrast, text enlargement and error recovery.
A user task becomes a reviewed interface with explicit pending, accepted and recovery states.
What you receive
Journey maps and interactive prototypes for the agreed workflows.
Figma components, design tokens and content rules.
Interaction and state specifications your developers can build from.
Task scenarios to use when accepting the built interface.
How we engage
We review the prototype with you through complete tasks: choosing the right account, inspecting a record, authorising an operation and confirming its outcome. The design can be handed to your own developers, or we can continue into the build in Blazor, MAUI or Windows and compare the working product with the accepted journey 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.
A smart contract puts your rules for value and authority on a blockchain, where they must behave exactly as specified. Sphere 10 designs and builds contracts for tokens, digital assets, DeFi, governance and business settlement, together with the wallets, applications and operating controls that make them a usable product.
What we build
Tokens and digital assets. Fungible tokens, NFTs and multi-token collections on Ethereum-compatible networks, with explicit minting, burning, approval and transfer rules, including permissioned assets with identity checks.
Vaults, staking and settlement. Vesting, escrow, staking, rewards and vaults, plus integrations with Uniswap and Aave.
Wallets and governance. Signed approvals, smart accounts, Safe multi-signature treasuries, proposal voting and controlled upgrades.
Polkadot. Contracts on Polkadot Hub, custom chain logic built in Rust with the Polkadot SDK, and maintenance or migration assessment for existing ink! contracts.
Application integration. C# services track each transaction from submission to confirmed business result and recover from node failures.
Authority controls the contract transition; confirmed events feed a recoverable C# read model.
What you receive
Contract source, tests and deployment evidence for the named network.
A register of who holds each administrative power.
Application integration code and authorised operator interfaces.
Monitoring, key succession and incident runbooks with named ownership.
How we engage
We start with one exact transaction, a real movement of value or authority, and specify its preconditions, permitted changes and completion before building the contract. Testing challenges the contract with unauthorised callers, replayed signatures and economic edge cases, and deployments and upgrades are rehearsed. Findings from specialist review are tracked through remediation and retesting.
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.
Choose the Right Ledger|A Buildable Chain Strategy
Before you fund a blockchain project, you need to know whether a shared ledger serves your requirement better than a conventional system, and what it would take to build and run. Sphere 10 turns a blockchain proposal into a decision you can act on, with an architecture, an operating model and a cost profile your decision-makers can examine.
What we do
Name the shared trust problem. We identify the parties that cannot rely on a single operator, the facts they must agree on and the rights each participant keeps.
Compare against a conventional design. The ledger options are assessed beside a database-backed .NET application with a signed audit trail, using the same privacy, governance and operating requirements.
Choose network and governance together. For public Ethereum, a rollup, Hyperledger Fabric, Besu or Polkadot we assess who controls upgrades, administrative keys, node access and fees.
Prototype the hardest part. A working prototype exercises one complete transaction, including rejection and recovery, and measures cost and latency under stated conditions.
The assessment connects a shared trust requirement to a network model, a working proof and an owned delivery plan.
What you receive
An architecture and decision record with the alternatives considered and the assumptions still open.
Prototype source and test results.
A prioritised delivery backlog with the acceptance evidence required.
Named responsibilities for hosting, monitoring, upgrades and incidents.
How we engage
We trace one real transaction from the party that starts it through to settlement, and build the recommendation from that. The resulting package is yours. It can progress into a build with us, or give another engineering team what they need to continue. The decision record also states what should prompt you to reconsider the choice as participants or workloads change.
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.
A token represents an obligation your organisation takes on, so its rules for supply, authority and redemption need to be settled before deployment and explainable afterwards. Sphere 10 builds fungible tokens, membership rights, allocation instruments and redemption mechanisms, with the contract, services and operator tools delivered as one system.
What we build
Define the unit of value. We specify what one token represents, its precision, its supply rules and the obligation created when it is issued or redeemed.
Set the authority model. Issuing, burning, freezing, treasury and upgrade powers are each mapped to a role with a succession procedure.
Use the right platform. ERC-20 on Ethereum-compatible networks, Solana token programs or Polkadot assets, with vesting schedules and regulated transfer rules where your specification requires them.
Reconcile to your records. Services link each issuance to its approval and beneficiary, and reports explain allocations, transfers, redemptions and outstanding liabilities.
Issuance, transfer and redemption obey contract invariants and reconcile to the application ledger.
What you receive
The token contract or configuration with its source, tests and deployment scripts.
A record of opening balances, role assignments and deployed configuration.
Operator interfaces and reconciliation reports.
Procedures for treasury approvals, key succession and monitoring.
How we engage
Supply policy, custody, restrictions and recovery are your product decisions. We turn them into executable rules and acceptance scenarios. Acceptance checks that supply adds up after minting, transfer, burning and redemption, that unauthorised and duplicate requests are refused, and that deployment and role transfer have been rehearsed. The release plan can include independent review and specialist legal input.
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.
Chain Events Into Action|Recover, Replay, Reconcile
Chain data becomes useful once it reaches your applications, financial records and workflows reliably. Sphere 10 connects blockchain networks to your business systems, covering transaction submission, payment observation, contract events, node imports and business-facing APIs, with clear ownership of each fact on either side.
What we build
Define when a record is complete. We agree when a chain observation is enough to update your business record, and how that update is reversed or reconciled if the observation changes.
Connect the networks you use. Ethereum and compatible chains, Bitcoin, Polkadot and Solana each get an adapter that follows how that network works.
Recover without duplicates. Connectors keep checkpoints and processing outcomes, so an import can resume and a message can be handled again without repeating a payment or allocation.
Give staff visibility. APIs and reports show pending, confirmed, disputed and failed items and let an operator trace any record to its source.
A checkpointed reader validates observations, commits idempotent business updates and reconciles before resuming.
What you receive
Connector source with its data model and versioned interfaces.
Reconciliation reports that identify missing, repeated or inconsistent observations.
Operational dashboards and deployment configuration.
Recovery runbooks and the test fixtures used for acceptance.
How we engage
Recovery is accepted as part of the delivered feature. During acceptance we stop nodes, interrupt imports and replay a recorded range of chain data, then show that totals can be explained and no business action was repeated. Our BlockchainSQL product is a working reference for Bitcoin data ingestion into SQL.
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.
Examine the Whole Scheme|Evidence Behind the Bytes
Choosing a sound algorithm is only one layer of a cryptographic design. The data formats, keys and application behaviour around it need the same scrutiny. Sphere 10 reviews signing, encryption, hashing, key derivation and integrity schemes in new designs and existing systems, and gives you reproducible findings with corrections you can implement.
What we do
Set the threat model. We state what an attacker can access, choose, capture and compromise before deciding what the scheme must protect.
Trace the exact bytes. We document what is signed or encrypted, how it is encoded and what the recipient rejects, including replayed and malformed messages.
Review keys and randomness. Key generation, custody, rotation, recovery and retirement are examined together with the library configuration.
Test across implementations. Published test vectors and cross-implementation fixtures confirm that your client, server and supported runtimes agree, and that altered messages are refused.
Plan migrations. This includes assessing the post-quantum standards FIPS 203, 204 and 205 for compatibility with your protocol.
The analysis connects exact message bytes, key operations and peer verification to lifecycle and adversarial test evidence.
What you receive
Findings that record the affected construction, prerequisites, reproduced behaviour and correction.
A specification of the construction as your application uses it.
Test vectors and a test harness your team can rerun.
Key-management operating notes and, where needed, a migration plan.
How we engage
The scope names the exact implementation and environment under review. After corrections are applied, we retest them against the original cases and record the evidence. Side-channel assessment, standards conformance and validated-module requirements are assessed within a defined scope tied to your threat model.
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.
