Capability 07

Decentralised systems, soberly built.

Secure, scalable blockchain applications — smart contracts, tokenisation, supply chain provenance, DeFi and NFT infrastructure.

Start a project → Read the FAQ

Overview

Blockchain carries a discipline most software does not: deployed contract code is often immutable and always adversarial. There is no quiet patch on Monday morning. Every bug is public, permanent and directly monetisable by whoever finds it first, which changes how the work has to be done.

We build decentralised systems with that reality in front of us — threat modelling before implementation, exhaustive testing including adversarial cases, and external audit before anything touches mainnet. We are also straightforward about when a distributed ledger is the wrong answer, which is more often than the market suggests. A database with good access control solves many of the problems blockchain gets proposed for.

All capabilities

Agentic Systems Product Development App Development Web Development UI/UX Design Artificial Intelligence Blockchain & dApps AR & VR Development Animation — 2D & 3D Start a project →

What we build

The things you actually receive.

Concrete deliverables rather than adjectives — this is the work, itemised.

Smart contracts

Solidity contracts written for audit and adversarial review from the first line, not retrofitted for it.

dApp interfaces

Front ends that make wallet interaction, transaction states and gas comprehensible to non-crypto users.

Tokenisation

Asset-backed and utility token systems, designed with the regulatory position considered rather than assumed.

Supply chain provenance

Verifiable chains of custody where multiple parties need shared truth without a trusted intermediary.

DeFi components

Protocol integrations, liquidity mechanics and yield infrastructure with economic as well as code review.

Wallet & custody integration

Key management, multi-signature and custody flows — the part users lose money through most often.

How we approach it

Where this discipline goes wrong.

Four decisions that separate work which lasts from work that has to be redone.

Step 01

Challenge the premise first

We open by asking whether this needs a blockchain at all. If there is no trust problem between parties, a conventional database is cheaper, faster and reversible. Being told this early is worth more than a project nobody needed.

Step 02

Threat model before implementation

Reentrancy, oracle manipulation, front-running, access control and upgrade paths are considered before code exists, because they cannot be meaningfully added afterwards.

Step 03

Test adversarially

Unit tests, fuzzing, invariant testing and fork testing against real chain state. We assume every function will be called in the worst possible order by someone with a financial motive.

Step 04

Audit before mainnet

Independent audit is a required step, not an optional one, and we build to be audited — clear, minimal, documented contracts that a reviewer can actually reason about.

Engagement

How this one is usually run.

The same engineering practice applies at every size. What changes is the shape of the team.

Good fit

Focused Build

One application or integration, defined scope and price.

Good fit

Product Team

A full delivery team owning the product end to end.

Less common

Enterprise & Government

Multi-team delivery against audit and procurement requirements.

A contract system through to audit typically 3 to 5 months, including audit turnaround and remediation.

Typically built with

Solidity
Foundry
Hardhat
TypeScript
ethers.js
IPFS
The Graph
OpenZeppelin

Questions

The ones worth asking.

Including the answers that lose us work — those are the ones worth publishing.

Do we actually need a blockchain?

Frequently not, and we would rather say so at the start than take the work. The test is whether multiple parties who do not trust one another need to agree on shared state without an intermediary. If one organisation controls the data, a database is the better engineering answer in nearly every respect.

How do you handle smart contract security?

Threat modelling before implementation, established audited libraries rather than novel cryptography, extensive adversarial testing, and independent external audit before mainnet deployment. We also design upgrade and pause mechanisms deliberately, since those are themselves a common attack surface.

Which chains do you work with?

Primarily EVM-compatible chains, where the tooling and audit ecosystem are strongest — which matters more for security than raw chain performance. Chain selection should follow from where your users and liquidity already are, not from a technical preference.

What about gas costs and scalability?

Both are design constraints from the outset — storage layout, batching and where computation belongs on or off chain. Layer 2 deployment is usually the right answer for consumer applications; we will model the cost per transaction at your expected volume before committing to an architecture.

Can you help with the regulatory side?

We are engineers, not lawyers, and you will need proper counsel — particularly for anything touching tokenisation or financial instruments in Singapore. What we do is build so that regulatory requirements such as transfer restrictions or reporting are technically achievable, and flag where a design choice would create a problem worth asking your counsel about.

What happens if a bug is found after deployment?

This is why the response plan is designed before launch rather than during an incident: pause mechanisms, upgrade paths where appropriate, and a defined disclosure process. Immutability means the mitigation strategy has to exist in the architecture, because it cannot be improvised afterwards.

Often paired with.

Most engagements draw on more than one capability. These are the usual neighbours.

Get in touch

Let's talk about blockchain & dapps.

Tell us what you're trying to ship. We'll tell you honestly whether we're the right team for it — and what it would take.

Prefer email? info@triyant.sg

We reply within one business day. Your details are used only to respond to this enquiry and are never shared with third parties.