Web3 development
Development of Web3 solutions that people trust with their money: smart contracts, wallets, trading and staking platforms, decentralised applications.
Let us start with what exactly we build. Smart contracts for the task at hand: issuing and moving tokens, distributing rewards, escrow, voting, paid access. Wallets, custodial and non-custodial, with multisig, transaction signing and access recovery. Trading venues: order books, swaps, staking, accruals. Decentralised applications end to end, from the contract to the interface. And ordinary products where the blockchain is responsible for one specific thing, say the immutable recording of a document, while everything else works like a familiar service.
We choose the network by calculation rather than by habit. The products we ran lived in Ethereum, Binance Smart Chain and other EVM-compatible networks, and for the end user the difference between them comes down to the fee per operation and the time it takes to confirm. So the network, the data storage model and the question of what is worth putting into a contract at all and what should stay on the server are settled at the architecture stage and costed in money.
We work both from scratch and with someone else's code, and we are no worse at the second. In the Ubix.Network ecosystem the products had been built at different times by different teams: each with its own architecture, its own design, documentation in some places and none in others. We brought it to a single form. The wallet, the exchange, the staking platform and the network explorer got a shared architecture, shared interface components and a shared release procedure, and part of the technical solutions we brought there ready-made from earlier projects. So going through someone else's code and pulling disparate services into one working system is routine work for us.
A word on the cost of a mistake, because here it is different. In an ordinary product a miss is closed by the next release, while in a blockchain a deployed contract cannot be recalled and a transaction cannot be rolled back. That is why contracts are covered with tests, go through an internal review and are prepared for an external audit by a specialised team, while the permissions inside a contract are cut to the minimum at the design stage. This is not over-caution, it is the normal way of working where other people's money is at stake.
Design, frontend, backend and infrastructure sit inside one team, so the wallet interface and the contract logic never drift apart between contractors. If the product has not been tested on real people yet, it makes more sense to start with a prototype or an MVP. What we took away from working in blockchain beyond the code is written up in our Web3 experience.
What the service covers
Any combination of the items below can be taken on its own.
We design and write contracts for the task at hand, cover them with tests and prepare them for an external audit.
Non-custodial and custodial solutions: keys, transaction signing, multisig, access recovery.
Order books, swaps, staking, reward distribution - from order matching to the trader interface.
Connecting to EVM networks and beyond: nodes, indexers, webhooks, transaction monitoring.
Threat model, code review, least privilege, preparation for an audit and incident analysis.
Design and frontend for decentralised applications: transaction and error states people can understand.
How we work
We talk it through and record the goal, the constraints and what has already been built. The output is a list of hypotheses and risks.
We choose the network, the stack and the data storage model, describe the components and give an estimate by stage.
Two-week iterations with a demo: contracts, backend, interface. Every iteration can be seen live.
Unit and integration tests, a testnet run, preparation for an external audit and fixes based on its findings.
Deployment to mainnet, monitoring, on-call duty for the first weeks and a plan for the further development of the product.
Stack and tools
Cases for this service
Frequently asked questions
Mainly EVM-compatible networks and layer two solutions. If a project calls for a different network, we estimate that separately at the architecture stage.
In the vast majority of cases a contract in an existing network is enough, and it costs an order of magnitude less. Your own network is justified when there are requirements a public network cannot meet: a closed set of participants, your own fee rules, requirements on where data is stored. We cost both options at the architecture stage and say so if you do not need a network of your own.
We run an internal review and prepare the code for an external audit by a specialised team, then close the findings.
Yes, this is a common scenario: we build a minimal version with the key scenario, ship it to a testnet and check demand before full development.
Everything is set by the contract, and we put it in writing at the specification stage, before the work starts. During the project the team works either on our infrastructure or on yours: the choice depends on the complexity of the project and on whether you already have infrastructure in place. Every approved stage is transferred to your servers and your repository, so the work accumulates on your side rather than ours. Once the project is closed, all code, materials and documentation are handed over to you together with the rights to them.
Related services
Shall we discuss your task?
Tell us what needs to be done and we will come back with an estimate, the team composition and a plan for the first two weeks.