Skip to content

Case study Trading

Trading software with smart contracts

Our client, an experienced commodities trader, came to unicrew with a detailed PRD (Product Requirements Document) to develop the trading platform.

unicrew built a private B2B trading platform for an experienced commodity trader who arrived with a detailed PRD: a marketplace for trading goods, where contracts are signed as smart contracts on the blockchain (Ethereum), paired with an integrated CRM. Security policy and access control shaped the build, and an administrator keeps control of everything that happens inside the marketplace.

Wheat field under a cloudy sky, representing the commodities traded on the platform
Focus
Trading, CTRM
Market
Switzerland
Engagement
Full build from a PRD
Stack
Node JSEthereum

Project overview

Our client is an experienced commodity trader who came to unicrew with a detailed PRD (Product Requirements Document) describing the main business processes and user flows. The objective was to develop a fully functional private platform for trading, built from two main components:

  • A marketplace for B2B trading of goods, with smart contracts signed via blockchain.
  • A CRM system integrated with the marketplace, with different communication capabilities.

Business analysts researched the client’s ideas and turned them into features the client and the development team could work from.

The challenge

The platform needed a strong security policy and robust access controls on several levels, and the client kept improving its business processes throughout development, which affected the build. That created several challenges:

  • Additional access-policy requirements endorsed during the pilot period forced a reconfiguration of the application’s logic. This was a non-trivial change, limited by delivery time, that required new logic at many points with the ability to enable or disable many features. In some cases we had to correct users’ roles and create alternative user flows.
  • The project aimed to earn a profit as a percentage of the contracts executed through the marketplace. To reduce the risks of losing confidential information and to avoid hidden deals, one goal was to keep all negotiation, communication, and contract signing within the marketplace.
  • The contracts needed a consistent architecture for saving and exchanging them under the performance and security requirements, alongside a user-friendly interface connected by API to third-party services like messengers and email.

The solution

unicrew’s team created a web application with complex logic that ultimately met the client’s expectations. The marketplace carries all the necessary integrated communications, each subject to specific rules and restrictions that an administrator manages:

  • Internal chat
  • WhatsApp
  • Calls with history
  • E-mails
  • App notifications

Contracts are signed using Ethereum smart contracts. Given the non-functional requirements, developers also implemented a microservices architecture: the application is built as independent components that run each application process as a service (built with Node.js). Because they run independently, each service can be updated, deployed, and scaled to meet demand for specific functions.

For interaction between the website’s backend and the blockchain, unicrew’s solution architects used IPFS (a peer-to-peer hypermedia protocol), which enabled higher bandwidth for data exchange and made the service faster and more resilient.

The result

The trading platform will give all stakeholders one place to find what they are looking for, negotiate, and reach an agreement. Traders and brokers can do their job inside it, selling and buying commodities. The administrator has control and ownership of all activity in the marketplace, and that is what makes market players willing to trust it.

The pilot period is there to show the client the app’s strengths and weaknesses, and how market players actually behave, before a global launch. The settings were built to be flexible enough that the client can run the business on its own terms without deals slipping past.

Commodity trading is one of the domains our business analysts and engineers work in; the CTRM/ETRM page covers what that includes. What clients say about working with us, in their own words, is on our client reviews page.

What the client says

We had a great experience in working with Artelogic and their team: very professional and knowledgable, ready to go the extramile in order to deliver high-quality products.

Great advices on the best technology solutions to adopt (including blockchain).

Ready to go the extra mile in supporting the client at 360 degrees.

Yaohui XUCo-Founder, Commodity Trading CompanySwitzerland
Clutch
5.0

Unified rating across 61 verified client reviews

See this review on goodfirms.co All client reviews

05/Technologies

Technologies on this project

Backend

AI & Data

  • Ethereum

06/Quick answers

The questions behind the project

What did unicrew build for the commodity trader?

A private B2B trading platform in two parts: a marketplace for trading goods, where contracts are signed as smart contracts on the blockchain (Ethereum), and a CRM integrated with that marketplace. The marketplace carries the communication a deal needs, internal chat, WhatsApp, calls with history, e-mails and app notifications, each subject to specific rules and restrictions an administrator manages. The client arrived with a detailed PRD describing the business processes and user flows.

Why microservices, Ethereum and IPFS on this platform?

Each piece answered a specific requirement. Contracts are signed using Ethereum smart contracts. Given the non-functional requirements, developers implemented a microservices architecture, with the application built as independent components that each run one application process as a service in Node.js, so any service can be updated, deployed and scaled to meet demand for a specific function. For interaction between the backend and the blockchain, unicrew's solution architects used IPFS, a peer-to-peer hypermedia protocol, which gave higher bandwidth for data exchange and made the service faster and more resilient.

How did the build absorb requirements that changed mid-project?

The client kept improving its business processes while the platform was being built. Additional access-policy requirements endorsed during the pilot period meant reconfiguring the application's logic: new logic at many points, the ability to enable or disable features, and in some cases corrected user roles and alternative user flows. That was a non-trivial change and it was limited by delivery time. When business processes are evolving during development, plan for configurable features early to avoid costly changes later.

What does unicrew bring to a trading or CTRM build?

Business analysts who can take a set of business ideas and turn them into features a client and a development team can both work from, and engineers and solution architects with marketplace, CRM and on-chain contract work behind them. Our CTRM/ETRM page sets out the wider domain. What carries to the next engagement is the team and what they learned.

When is a smart contract the right way to sign a trading contract?

When both sides need to prove later what was signed and when, and neither side should own that record on its own. That is the settlement step, and it is a narrow one. If your counterparties already accept a central record, or your terms get renegotiated after signature, a conventional database with a real audit log is cheaper to run and far easier to change. Treat a chain as a fit for one step rather than as the architecture for a whole platform.

Have a project in mind?

Tell us what you are building. We will map the fastest route from where you are now to a working product, no obligation and no sales script.

Book a scoping call

Thank you

Thanks for your message. We will get in touch with you shortly.