Skip to content
HASHXLABS
Work

Selected work, built to hold up

Client sites you can open today, and engagements described under NDA: what was built, and how it was tested, as it was delivered.

Discuss a similar project Read the case studies

Fig. 01 — Four engagements, as delivered

01DeFi protocol02Asset manager03Fintech startup04Logistics operator

Illustrative interfaces, not client screenshots. Pick one to read how it was built.

Live projects

Shipped, live, and one click away

Two client sites we built, running in production today. Scroll through them here, then open the real thing.

01Web3 · Creator economy

SinghCoin

A home for a creator token and its ecosystem

SinghCoin connects social content, digital collectibles, events and token rewards. The site explains the ecosystem, introduces its new app, SlaySpace, and puts the SINGH token's on-chain details one click from BscScan.

What we built
  • Kinetic hero and motion system, hand-coded without a framework
  • Ecosystem pages for social, collectibles and events
  • Token section with the BEP-20 contract and a BscScan link
Token
SINGH
Standard
BEP-20
Visit singhcoin.io
  • HTML & CSS
  • Vanilla JS
  • Cloudflare
  • BNB Chain
The SinghCoin website on desktop: a full-page screenshot of singhcoin.io.

Real screenshots of the live site, captured October 2026.

02Software consultancy · Germany

BitNautics

A corporate site for a German software consultancy

BitNautics builds custom software, websites and automotive embedded systems from Rosbach, Germany. Their site presents three service lines, the team and open roles, and turns visitors into quote requests.

What we built
  • Responsive company website, designed and built end to end
  • Service pages for web, automotive and custom software
  • Careers, blog and quote-request flows
Based in
Rosbach, Germany
Services
Web · Automotive · Software
Platform
WordPress + Elementor
Visit bitnautics.com
  • WordPress
  • Elementor
  • Responsive
  • SEO
The BitNautics website on desktop: a full-page screenshot of bitnautics.com.

Real screenshots of the live site, captured October 2026.

Engagements under NDA

How the work was built and tested

Client names stay private. We are happy to walk through the architecture and test approach of any of these on a call.

01DeFi protocol

Cross-chain AMM with staking and yield routing

A constant-product AMM with a staking module and cross-chain message passing, with invariant tests over every flow.

Standard
ERC-4626 vault standard
Client
Under NDA name withheld
  • Solidity
  • Foundry
  • LayerZero
  • Slither
  • Echidna
Discuss a similar build
Illustrative interface for a cross-chain AMM: a token swap card, a liquidity pool chart, a staking vault and a bridge between two chains.
Illustrative interface, not a client screenshot.
The challenge

The team needed liquidity on two chains with staking rewards that could not be double-claimed across them.

How it fits together
  1. User
  2. AMM pool
  3. Staking vault
  4. Router
What we built
  • Constant-product pool with fee accounting
  • ERC-4626 staking vault
  • Cross-chain router over LayerZero
  • Keeper scripts for reward routing
What we tested
  • Reentrancy guards on every external call path
  • Swap, deposit and withdrawal invariants in Foundry
  • Cross-chain replay and ordering cases
  • Static analysis with Slither, fuzzing with Echidna
02Asset manager

Permissioned real-world asset tokenization portal

Identity-gated transfers with on-chain compliance checks, a claims registry and automated holder distributions.

Standard
ERC-3643 permissioned token
Client
Under NDA name withheld
  • Solidity
  • ERC-3643
  • Polygon
  • Chainlink
Discuss a similar build
Illustrative issuer console for a permissioned asset token: an investor registry with verification status, compliance rules, a distribution chart and the issuance flow from investor to token.
Illustrative interface, not a client screenshot.
The challenge

An issuer needed tokens that only verified investors could hold, with distributions that reconcile to the cent.

How it fits together
  1. Investor
  2. Claims
  3. Compliance
  4. Token
What we built
  • Permissioned token with modular transfer rules
  • Claims registry tied to a KYC provider
  • Issuer console with freeze and recovery
  • Pro-rata distribution engine
What we tested
  • Transfers to unverified wallets always revert
  • Issuer and agent roles cannot overlap
  • Distribution rounding never exceeds the pool
  • Rule changes behind a timelock
03Fintech startup

Multi-signature custody wallet with a policy engine

Threshold-signature vaults with per-transaction spend policies and hardware-backed keys, on web and mobile.

Standard
2-of-3 threshold signing
Client
Under NDA name withheld
  • React Native
  • Node.js
  • PostgreSQL
  • AWS KMS
Discuss a similar build
Illustrative custody console: a treasury vault, a pending transfer with two of three approvals, a policy engine and the signing path from client to key service.
Illustrative interface, not a client screenshot.
The challenge

The product needed shared custody where no single device or person could move funds alone.

How it fits together
  1. Client
  2. Policy
  3. Signer
  4. KMS
What we built
  • Policy engine for limits, allowlists and approvals
  • Signing service over AWS KMS
  • Web and React Native clients on one API
  • Audit log of every approval
What we tested
  • No path signs without two approvals
  • Policy bypass attempts through the API
  • Key rotation without downtime
  • Replay of approved requests
04Logistics operator

Retrieval-augmented agent over internal documents

Hybrid retrieval over a chunked corpus, with a tool-calling agent and a human approving every write.

Standard
Hybrid vector + keyword
Client
Under NDA name withheld
  • Python
  • pgvector
  • FastAPI
  • LangChain
Discuss a similar build
Illustrative assistant interface: a chat answer with source citations, the retrieved documents, an approval queue for an ERP update and the pipeline from question to approval.
Illustrative interface, not a client screenshot.
The challenge

Operations staff spent hours searching manuals and emails before updating the ERP.

How it fits together
  1. Question
  2. Retriever
  3. Agent
  4. Approval
What we built
  • Hybrid retrieval over pgvector and keyword search
  • Tool-calling agent with read-only defaults
  • Approval queue for ERP writes
  • Evaluation set from real questions
What we tested
  • Answers cite their sources
  • No ERP write without approval
  • Prompt injection from documents
  • Regression runs on every change

Building something similar?

Tell us what you are building and what must not go wrong. An engineer who would work on it will reply.

Start a project info@hashxlabs.com