The problem TrustLayer solves

Prepaid service businesses such as gyms, beauty salons, and tuition centres ask customers to pay today for services delivered over the following weeks or months. This creates a trust gap: a business may begin deteriorating operationally while customers continue buying packages because they cannot see the warning signs.

TrustLayer turns operational risk signals into a verifiable performance commitment.

The system derives a merchant health score from operational data, uses that score to determine a dynamic performance-bond requirement, and records the merchant’s commitment on Sui. If risk increases, the required protection can increase and the smart contract can initiate a rule-based slash-and-challenge process.

Customer payments do not need to move onto the blockchain. They can remain on traditional payment rails while Sui provides a transparent commitment and enforcement layer.

TrustLayer helps:

• Consumers assess the risk behind prepaid purchases.
• Merchants turn strong operational performance into a visible trust signal and potentially lower bond requirements.
• SaaS and POS platforms transform operational data they already manage into a new trust feature.

Our hackathon prototype runs on Sui Testnet. It demonstrates clearly labelled simulated operational events, deterministic health scoring, live shared Merchant objects, wallet-signed bond deposits, health updates, slash initiation, and counter-evidence. The browser derives the health score, while the authorized wallet submits the resulting score on-chain.

Challenges we ran into

1. Abandoning our original custody model

Our first design locked 100% of a consumer’s prepayment in a Sui Move contract and released it when milestones were completed. We ultimately rejected this approach for three reasons:

It created adverse selection: responsible merchants would not want all their working capital locked.

Service fulfilment can be subjective, and a smart contract cannot reliably decide whether an experience was “good.”

Holding customer funds could introduce serious regulatory and licensing concerns in Malaysia.

We kept the underlying trust problem but replaced full payment custody with a dynamic merchant performance bond. Customer payments remain on existing payment rails, while Sui provides the transparent commitment and enforcement layer.

2. Finding a gap in our original risk trigger

Our initial concept relied heavily on refund requests accumulating. We realised this was incomplete: a merchant could disappear before customers had time to request refunds.

We expanded the design to consider multiple independent operational signals, including attendance anomalies, unresolved maintenance issues, and merchant disappearance. In the current prototype, these inputs are clearly labelled simulations used to demonstrate deterministic health scoring and the on-chain challenge flow.

3. Confronting the oracle and incentive problem

TrustLayer ultimately depends on operational data supplied by merchants or SaaS/POS platforms. That creates a difficult incentive problem: a platform may benefit from keeping its merchants’ scores healthy, and a blockchain cannot force an external platform to report an event it chooses to omit.

We did not pretend to solve this completely. Our proposed future design treats prolonged data silence as a negative signal rather than allowing missing data to appear healthy. This remains a roadmap concept, not a live integration in the current prototype.

4. Recognising the limits of the kiosk approach

We explored a standalone kiosk as a cold-start option for merchants without an integrated SaaS platform. However, a kiosk can still receive inaccurate data before anything reaches the blockchain.

Sui can prove that submitted records were not altered afterward, but it cannot guarantee that every original input was truthful. We therefore present the kiosk honestly as a simulated, imperfect onboarding bridge, not a fully trustless data source.

What we learned

The hardest part was not writing the first contract. It was identifying where our original assumptions failed, discarding mechanisms that created new risks, and clearly separating what the prototype proves today from what still requires stronger oracle design, governance, and regulatory analysis.