Dear community,

‍

We're launching a new series of posts to keep you up to date with the latest progress on the development of our tokenization platform. It will have a technical focus and present a mix of the latest features and improvements that have been developed, as well as a “Behind the Screens” section where we give honest but tongue-in-cheek insights into developer life and share the biggest challenges and pains we've had to overcome. We hope you enjoy our new series!

What Happened Last Month?

Here we will discuss what we have achieved and what has been implemented in the last month. Let’s dive right in!

Optimized App Structure

We have expanded the structure and layout of our app. Whereas before we had a simple navbar, we have now opted for a clear sidebar layout. As the functionality of our tokenization keeps growing, and we’re adding more and more features such as a secondary market, professional and compliant admin, transaction and token mangement, and many more, we’re starting to “run out of space” to fit all the features in a simple navigation bar. Now we have more than enough space for all the features for both, issuers and users, so they can easily find their way around the app!

Implemented the ONINO Design Language

So far, we have used a clean and neutral design language inspired by the state-of-the-art components of shadcn/ui, mainly to have a neutral base for the implementation of our clients' branding. But now we have decided to adopt our ONINO design language, which we also use for our other applications. We love the look and feel!

Added Guided Onboarding Workflow

We have implemented a fully guided onboarding workflow that makes the tokenization process as convenient as possible for issuers. Our aim is to reduce friction and entry barriers as much as possible. Issuers are now guided through the entire process step by step and receive detailed explanations of the individual processes.

Upgraded Authentication & Security System

We have integrated an additional layer of security into our authentication and security system - for maximum protection of our users' and issuers' data. More on this in the technical section below!

⭐️ The Highlight: Launch of the Public Demo Version 🚀 

‍

Normally, our tokenization platform is only accessible to our business customers, who get their own customized version of it deployed on their domain. 

We have therefore decided to provide a simplified, public demo version, especially for our community - running on our very own ONINO Testnet.

While this version has a reduced range of functionality compared to the real production customer version (as some features are associated with direct costs or, such as investor management, simply don't make sense in a public test environment), we still want to give our community an idea of what it looks like for our customers to run their own instance of the ONINO tokenization platform - and how easy it can be for everyone to tokenize assets! 

We also want to use this public, simplified demo version to put our application, our infrastructure, and the integration of the two to a broader test.

‍

With the demo, we have also launched a contest - create your tokenization project and get a chance to win free usage of the tokenization platform in the future ONINO Mainnet! 

‍

If you haven't yet, give it a try here: 

‍

https://testnet.tokenization.onino.io/   

Behind the Screens 🤓

This is our new section for brutally honest (possibly slightly annoyed) developer insights, where we talk openly and tongue-in-cheek about our biggest hurdles - and how we solved them.

To understand the challenge, we need to create an initial awareness. Our backend runs on Supabase, an open-source and state-of-the-art Backend-as-a-Service (BaaS) provider based on Postgres databases. Following best practices, we implemented Row-Level Security (RLS), which defines exactly who can access what data in the database (e.g. as a user, I can only see my own purchases). To add a further layer of protection, we have introduced role-based access control (RBAC). Put simply, this means that a user's role (e.g. user or administrator) is encoded directly in the access token they receive when they log in. This access token is sent to the database with every request, and the database then decodes the access token and checks at RLS-level whether the user is allowed to perform the desired action (e.g. an administrator can view all purchases, a normal user cannot). So far, so good, we have protected our user data with fine-grained access control at database level. Great!

Now we come to the next point. We have now also implemented a special middleware that can be thought of as a “guard” that every request to the app must pass through before it arrives at the server (e.g. to render an app page or access an API endpoint). Now, of course, we want to integrate the access control system described above into this middleware. To do this, we need to retrieve the access token from the request in the middleware, decode it, check the role encoded in the access token and decide whether a user is “allowed to pass or not”. However, there is a problem: our “guardian”, the middleware, runs on the server side. And the supabase function that returns the current access token is - you guessed it - not safe for server-side use. Well, now we have a problem. We had to find another way to manually parse and decode the token and verify the role, in a server-side, secure way. In itself this is not a big problem, but for some reason Supabase seems to arbitrarily decide what the format of the access token they issue looks like (and we obviously need to cover all cases). We're even in discussions with them in the Supabase Reddit. Oh, that thing gave us quite a headache!

But in the end, the ONINO team came up with a great solution, and now we have an invincible dragon guarding our tokenization platform! 

Think of it like this: If someone wants to access a page or API endpoint and is authorized to do so, their request is not even forwarded to the server. No chance for unauthorized data access. It was not easy, but definitely worth it in the end. One can never have enough security!

‍

We hope you enjoyed our new series! Which product and developer topics would you like us to cover more? Let us know what insights you are interested in! 

Your ONINO Development Team

‍