DEV Community: Dmytro Zahumennov

Building a Prediction Market on Chromia | Step 4 — Bets, Moderation, and Validation Rules

Dmytro Zahumennov — Wed, 14 May 2025 14:14:01 +0000

Today, we’ll start with a small fix to the event entity and expand it a bit. Let's add the mutable annotation to the is_closed and result fields so that we can update them later. Also we’re introducing a new field called status with three possible values: PENDING, APPROVED, and REJECTED. This is our way of adding moderation, so we don’t let unwanted content slip into the system. And finally, we’re adding the ability to configure the bet amount.

Here’s what the updated event looks like in oddly/entities.rell:

entity event {
    creator: ft4_account;
    question: text;
    created_at: timestamp = utils.last_known_time();
    mutable is_closed: boolean = false;
    expires_at: timestamp;
    mutable result: result_values = result_values.UNRESOLVED;
    mutable status: event_status = event_status.PENDING;
    bet_amount: integer;
}

Let’s update the create_event operation. But first, let’s clean things up a bit. Right now all the required checks are sitting directly inside the operation, and it looks a little overloaded. So we’re going to move those validations into a separate file to keep things neat and readable. Create a new file at oddly/requirements.rell and drop in the following functions:

function validate_question_length(question: text) {
    require(
        question.size() in range(utils.MIN_QUESTION_LENGTH, utils.MAX_QUESTION_LENGTH),
        "Question must be between 10 and 280 characters."
    );
}

function validate_expiration_period(expires_in_days: integer) {
    require(
        expires_in_days in range(utils.MIN_EXPIRATION_DAYS, utils.MAX_EXPIRATION_DAYS),
        "Expiration period must be between 1 and 365 days."
    );
}

function validate_bet_amount(bet_amount: integer) {
    require(
        bet_amount in range(utils.MIN_BET_AMOUNT, utils.MAX_BET_AMOUNT),
        "Bet amount must be between 1 and 1000."
    );
}

We simplified them a bit by using range() instead of plain comparison operators. And don’t forget to update utils/constants.rell:

val MIN_EXPIRATION_DAYS = 1;
val MAX_EXPIRATION_DAYS = 366;
val MIN_QUESTION_LENGTH = 10;
val MAX_QUESTION_LENGTH = 281;
val MIN_BET_AMOUNT = 1;
val MAX_BET_AMOUNT = 1001;

Now each validation lives in its own neat little place. Next up, let’s update the operation itself:

operation create_event(question: text, expires_in_days: integer, bet_amount: integer) {
    val account = auth.authenticate();

    validate_question_length(question);
    validate_expiration_period(expires_in_days);
    validate_bet_amount(bet_amount);

    val expires_at = utils.days_from_now(expires_in_days);
    create event ( creator = account, question, expires_at, bet_amount );
}

I also want to add a new value to result_values — VOID. This will come in handy when an event can’t be resolved for some reason. Maybe the event never happened, the question turned out to be invalid, or there’s simply not enough information to decide the outcome. So let’s update our result_values enum in oddly/enums like this:

enum result_values {
    YES,
    NO,
    UNRESOLVED,
    VOID
}

Now we just need to tweak the tests. We’ll update the create_event call to include the bet amount, and in test_create_event, we’ll throw in two extra checks, one for the event status and one for the bet amount. It should look like this:

function test_create_event() {
    val alice = rell.test.keypairs.alice;

    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    rell.test.tx()
        .op(open_strategy.ras_open(auth_descriptor))
        .op(strategies.register_account())
        .sign(alice)
        .run();

    rell.test.tx()
        .op(ft_auth_operation_for(alice.pub))
        .op(create_event("Will CHR be $10 in a week?", 7, 10))
        .sign(alice)
        .run();

    val events = get_events();

    assert_equals(events[0].creator.id, alice.pub.hash());
    assert_equals(events[0].question, "Will CHR be $10 in a week?");
    assert_true(events[0].created_at > 0);
    assert_equals(events[0].is_closed, false);
    assert_true(events[0].expires_at > events[0].created_at);
    assert_equals(events[0].result, result_values.UNRESOLVED);
    assert_equals(events[0].status, event_status.PENDING);
    assert_equals(events[0].bet_amount, 10);
}

Let’s pause here for now with adding new features to the events, so we don’t overload the MVP. Honestly, I’ve got tons of ideas and features I want to bring to life in this dapp. But the main goal right now is to ship a minimal but functional version. We’ll keep building and leveling it up from there until we shoot it into orbit 🚀

So for now:

the bet amount will be static
each account can vote only once per event
the result will be resolved manually by an admin

Alright, time to add an admin-only operation that lets moderators review and approve (or reject) events. In general, any admin operation brings a bit of the centralized world into our beautifully decentralized one, so in the future, we’ll definitely need to fix that. In oddly/module.rell we import the admin module like this:

import lib.ft4.core.admin;

Next, we create a new operation inside oddly/operations.rell. First things first, let’s make sure only an admin can call it:

operation moderate_event(event, event_status) {
    admin.require_admin();
}

And really, that’s all we need this operation to do, just update the event’s status. Nice and simple:

operation moderate_event(event, event_status) {
    admin.require_admin();

    event.status = event_status;
}

Maybe it would make sense to add extra checks here, like blocking re-moderation or preventing status changes from REJECTED to APPROVED. But for now, let’s keep things simple and just trust the admins 🙂

Time to test. First, we add the admin public key we generated earlier to the blockchain config. And for testing, we’ll generate a separate key just for that. Run the following command:

chr keygen --file .chromia/admin_test_keypair

Make sure the project structure looks exactly like this:

Then update chromia.yml so the system knows who the admin is in production and who gets admin powers during tests:

blockchains:
  oddly_development:
    module: development
    moduleArgs:
      lib.ft4.core.admin:
        admin_pubkey: x"030E7FE665AA55349A9503DD0DB8FA6CB2C1267A50A9F50A60A1EA34D4571FCDE3"
compile:
  rellVersion: 0.14.5
database:
  schema: schema_oddly
test:
  modules:
    - tests
  moduleArgs:
    lib.ft4.core.admin:
      admin_pubkey: x"035A93A7DDF932BB4742CE678D330BC1A586C442A1B6FE3244AA5209F311AF8C16"
libs:
  ft4:
    registry: https://gitlab.com/chromaway/ft4-lib.git
    path: rell/src/lib/ft4
    tagOrBranch: v1.1.0r
    rid: x"FEEB0633698E7650D29DCCFE2996AD57CDC70AA3BDF770365C3D442D9DFC2A5E"
    insecure: false
  iccf:
    registry: https://gitlab.com/chromaway/core/directory-chain
    path: src/lib/iccf
    tagOrBranch: 1.87.0
    rid: x"9C359787B75927733034EA1CEE74EEC8829D2907E4FC94790B5E9ABE4396575D"
    insecure: false

Next, in tests/development_tests, create a file called helpers.rell and add our test admin key there:

function admin_keypair() = rell.test.keypair(
    priv = x"820D5301627C33AF91C3BCBCE8BC32D36DF7BBE232FC76AF309AE2A2A36F97FA",
    pub  = x"035A93A7DDF932BB4742CE678D330BC1A586C442A1B6FE3244AA5209F311AF8C16"
);

Great. The admin is in place. Now we can move on to testing event moderation. We’ve already duplicated quite a bit of code in our tests, so it’s time to clean things up. Let’s start with a quick refactor. First, in development_tests/module.rell add the following import:

import core_accounts: lib.ft4.core.accounts;

Now in development_tests/helpers.rell let’s extract all the repetitive pieces that keep popping up in every test. We’ll start with account creation:

function register_account(user_kp: rell.test.keypair, auth_descriptor: core_accounts.auth_descriptor) {
    rell.test.tx()
        .op(open_strategy.ras_open(auth_descriptor))
        .op(strategies.register_account())
        .sign(user_kp)
        .run();
}

Next, let’s prepare some structs to help us pass parameters around more easily. In some of our helper functions, the number of parameters is getting out of hand, and passing them one by one would be painful. Structs to the rescue:

struct create_event_struct {
    user_kp: rell.test.keypair;
    question: text;
    expires_in_days: integer;
    bet_amount: integer;
}

struct create_event_must_fail_struct {
    user_kp: rell.test.keypair;
    question: text;
    expires_in_days: integer;
    bet_amount: integer;
    error_message: text;
}

And now, the functions themselves:

function create_test_event(params: create_event_struct) {
    rell.test.tx()
        .op(ft_auth_operation_for(params.user_kp.pub))
        .op(create_event(params.question, params.expires_in_days, params.bet_amount))
        .sign(params.user_kp)
        .run();

    return get_events()[0];
}

function create_test_event_must_fail(params: create_event_must_fail_struct) {
    rell.test.tx()
        .op(ft_auth_operation_for(params.user_kp.pub))
        .op(create_event(params.question, params.expires_in_days, params.bet_amount))
        .sign(params.user_kp)
        .run_must_fail(params.error_message);
}

function create_test_event_and_moderate(event: event, status: event_status) {
    rell.test.tx()
        .op(moderate_event(event, status))
        .sign(admin_keypair())
        .run();
}

Take a look at the create_test_event and create_test_event_must_fail functions. Since both take more than three parameters, we’re using a struct to pass them around. It’s way more convenient than stuffing a bunch of arguments into every call.

Now in the main test file, we replace all the direct calls with these helper functions and throw in one more test for event moderation. Let’s go.

function test_create_event() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    register_account(alice, auth_descriptor);

    val event = create_test_event(
        create_event_struct(
            user_kp = alice,
            question = "Will CHR be $10 in a week?",
            expires_in_days = 7,
            bet_amount = 10
        )
    );

    assert_equals(event.creator.id, alice.pub.hash());
    assert_equals(event.question, "Will CHR be $10 in a week?");
    assert_true(event.created_at > 0);
    assert_equals(event.is_closed, false);
    assert_true(event.expires_at > event.created_at);
    assert_equals(event.result, result_values.UNRESOLVED);
    assert_equals(event.status, event_status.PENDING);
}

function test_create_event_too_short_question_must_fail() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    register_account(alice, auth_descriptor);

    create_test_event_must_fail(
        create_event_must_fail_struct(
            user_kp = alice,
            question = "Too short",
            expires_in_days = 7,
            bet_amount = 10,
            error_message = "Question must be between 10 and 280 characters."
        )
    );
}

function test_create_event_too_long_question_must_fail() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    register_account(alice, auth_descriptor);

    val long_question = "A".repeat(300);

    create_test_event_must_fail(
        create_event_must_fail_struct(
            user_kp = alice,
            question = long_question,
            expires_in_days = 7,
            bet_amount = 10,
            error_message = "Question must be between 10 and 280 characters."
        )
    );
}

function test_create_event_exceeds_max_expiration_must_fail() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    register_account(alice, auth_descriptor);

    create_test_event_must_fail(
        create_event_must_fail_struct(
            user_kp = alice,
            question = "Will CHR be $100?",
            expires_in_days = 400,
            bet_amount = 10,
            error_message = "Expiration period must be between 1 and 365 days."
        )
    );
}

function test_create_event_zero_days_must_fail() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    register_account(alice, auth_descriptor);

    create_test_event_must_fail(
        create_event_must_fail_struct(
            user_kp = alice,
            question = "Will CHR reach $1 today?",
            expires_in_days = 0,
            bet_amount = 10,
            error_message = "Expiration period must be between 1 and 365 days."
        )
    );
}

function test_create_event_and_moderate() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    register_account(alice, auth_descriptor);

    var event = create_test_event(
        create_event_struct(
            user_kp = alice,
            question = "Will CHR be $10 in a week?",
            expires_in_days = 7,
            bet_amount = 10
        )
    );

    create_test_event_and_moderate(event, event_status.APPROVED);

    event = get_events()[0];

    assert_equals(event.status, event_status.APPROVED);
}

Let’s run the tests and boom — everything works:

TEST RESULTS:

OK tests.development_tests:test_account_creation (0.673s)
OK tests.development_tests:test_create_event (0.179s)
OK tests.development_tests:test_create_event_too_short_question_must_fail (0.126s)
OK tests.development_tests:test_create_event_too_long_question_must_fail (0.113s)
OK tests.development_tests:test_create_event_exceeds_max_expiration_must_fail (0.117s)
OK tests.development_tests:test_create_event_zero_days_must_fail (0.111s)
OK tests.development_tests:test_create_event_and_moderate (0.120s)

SUMMARY: 0 FAILED / 7 PASSED / 7 TOTAL (1.442s)

Now we’re moving on to betting functionality. As always, let’s start with the entity. We’re adding a new one called bet:

entity bet {
    key event, better: ft4_account;
    choice: choice_values;
    created_at: timestamp = utils.last_known_time();
}

We’ve created a composite key, which is an index that enforces uniqueness across two fields at once: event and better. This setup ensures that a single account can only place one bet per event. If they try to place another one, the system will throw an error. Simple, reliable, and exactly what we need.

One more thing worth highlighting is the event field. Here we’ve directly linked bet to event, creating a one-to-many relationship. In plain terms, a single event can have many bets attached to it.

Next, let’s add a validation rule to make sure users aren’t trying to bet on expired events. It’s a basic check, but absolutely essential. We’ll drop this into requirements.rell:

function validate_event_expiration(event: event) {
    require(
        event.expires_at > utils.last_known_time(),
        "Event has expired."
    );
}

This function simply checks that the event hasn’t expired yet. If the expiration time has already passed, we throw an error and prevent the user from placing a bet.

Alongside this, we’re also adding a very straightforward operation to place a bet. Nothing fancy, just straight to the point:

operation place_bet(event, choice: choice_values) {
    val account = auth.authenticate();

    validate_event_expiration(event);

    create bet ( event, account, choice );
}

We authenticate the account, make sure the event is still active, and then create the bet. Simple as that.

And just like we did with events, we add a simple query that returns all bets:

query get_bets(): list<bet> {
    return bet @* { };
}

For now, there’s no filtering or sorting, just a full list. Later on, we’ll definitely level this up.

We’ll be placing and testing bets more than once, so it’s a good idea to pull the main logic into helpers.rell to avoid repeating ourselves:

function create_test_bet(user_kp: rell.test.keypair, event: event, choice: choice_values) {
    rell.test.tx()
        .op(ft_auth_operation_for(user_kp.pub))
        .op(place_bet(event, choice))
        .sign(user_kp)
        .run();

    return get_bets()[0];
}

We’ll move the main test cases into a separate file
development_tests/bets_test.rell :

function test_place_bet() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    register_account(alice, auth_descriptor);

    val event = create_test_event(
        create_event_struct(
            user_kp = alice,
            question = "Will CHR be $10 in a week?",
            expires_in_days = 7,
            bet_amount = 10
        )
    );

    val bet = create_test_bet(alice, event, choice_values.YES);

    assert_equals(bet.event, event);
    assert_equals(bet.better.id, alice.pub.hash());
    assert_equals(bet.choice, choice_values.YES);
    assert_true(event.created_at > 0);
}

function test_place_bet_twice_must_fail() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    register_account(alice, auth_descriptor);

    val event = create_test_event(
        create_event_struct(
            user_kp = alice,
            question = "Will CHR hit $5 next month?",
            expires_in_days = 30,
            bet_amount = 10
        )
    );

    create_test_bet(alice, event, choice_values.YES);

    rell.test.tx()
        .op(ft_auth_operation_for(alice.pub))
        .op(place_bet(event, choice_values.NO))
        .sign(alice)
        .run_must_fail();
}

In the last test, we deliberately place a different choice (NO), but it still has to fail—because a single account shouldn’t be able to place two bets on the same event. That’s exactly what our composite key is here to prevent.

That’s a wrap for today. Time to exhale. I’m not yet sure what we’ll build next, but we’re definitely going to keep pushing forward. From now on, I’ll start skipping detailed test descriptions so we can focus more on the core logic. But don’t worry, you can always find all the tests in the repo if you need them. Let’s keep moving.

👈 Previous step | 💻 GitHub repo

Building a Prediction Market on Chromia | Step 3 — Creating Events and Writing Your First Operation

Dmytro Zahumennov — Mon, 05 May 2025 09:54:45 +0000

Today we’ll create our first entity, learn how to create events, write a simple query to fetch all events, and of course, test everything to make sure it actually works.

Let’s start with the basics. We’ll define our first entity, which is essentially just a SQL table. In it, we need to specify the field names and their types. The first entity will be called event. It will store all the core info about each event: the account of the user who created it, the question text, creation time, expiration time, a flag that shows whether the event is closed, and the result. I want to directly link each event to its creator’s account. For that, we’ll use the type ft4 account, which represents a user in the FT4 system. We import it from the FT4 library in oddly/module.rell like this:

module;

import lib.ft4.core.accounts.{ ft4_account: account };

The created_at field represents the timestamp of when the event was created. In Rell, the recommended type for this is timestamp. It stores time in milliseconds since the UNIX epoch, which is the standard way to handle time in blockchain environments. This makes it easy to sort, filter, and compare events by time. We don’t want to pass this value manually every time, so we’ll use a function that automatically sets the current time during creation. I’ll show you how that function looks a bit later.

The is_closed field is a boolean that tells us whether the event has already ended. By default, we’ll set it to false.

The expires_at field is another timestamp, which defines the expiration time for the event. The user will provide the number of days until expiration, and we’ll calculate the exact timestamp from that.

As for the result field, we’ll need something more flexible. We’ll define an enum to represent the possible outcomes of the event: yes, no, or unresolved. To do that, we create a file called oddly/enums.rell and drop in the following code:

enum result_values {
    YES,
    NO,
    UNRESOLVED
}

UNRESOLVED is the default value. It means the event is still open and the result hasn’t been decided yet.

Now let’s create the entities.rell file where we’ll define our first entity. It’s going to look something like this:

entity event {
    creator: ft4_account;
    question: text;
    created_at: timestamp = utils.last_known_time();
    is_closed: boolean = false;
    expires_at: timestamp;
    result: result_values = result_values.UNRESOLVED;
}

Boom. The entity is ready. Now let’s move on to operations. Inside the oddly directory, we create a new file called operations.rell. And to start things off, we’ll write a basic stub for our operation. It will take two parameters: the question text (question) and the number of days until the event expires (expires_in_days):

operation create_event(question: text, expires_in_days: integer) {

}

Before we can actually create the event, we need to know who is creating it. That’s where the authenticate function from the FT4 library comes in. But for everything to work properly, we need to do three things:

Import auth from FT4.
Add an auth_handler that defines what permissions a user needs to perform certain actions (in our case, creating an event).
Call auth.authenticate() inside the operation to extract the account of the user who triggered it.

In module.rell we add:

module;

import lib.ft4.core.accounts.{ ft4_account: account };
import lib.ft4.core.auth;

@extend(auth.auth_handler)
function () = auth.add_auth_handler(
    flags = ["T"]
);

And in operations.rell:

operation create_event(question: text, expires_in_days: integer) {
    val account = auth.authenticate();
}

Now we know exactly who’s calling the operation, and we can safely link the event to its creator.

Next up is validation. First, we want to make sure the question isn’t too short or too long. Second, we’ll check the expiration period — it needs to be a positive number and within a sensible range. A year sounds like a decent cap for now, but we can adjust it later.

So let’s set up the basics. Inside the oddly directory, create a subfolder called utils. In there, as usual, start with module.rell and keep it simple:

module;

Now add a new file called constants.rell, where we’ll define all the validation limits. This way, if you ever need to tweak the rules, you won’t be hunting through scattered code — just update them here:

val MIN_EXPIRATION_DAYS = 1;
val MAX_EXPIRATION_DAYS = 365;
val MIN_QUESTION_LENGTH = 10;
val MAX_QUESTION_LENGTH = 280;

We’ll also need two helper functions for handling time: one to determine when the event was created, and one to calculate when it should expire. Sure, we could use something like System.currentTimeMillis() — but that’s not how things work on a blockchain. Nodes don’t share a synchronized clock, and the only timestamp you can truly rely on is the one written into the block itself.

So we create a new file called time.rell inside utils, and define two functions there:

function last_known_time() = if (op_context.exists) op_context.last_block_time else block @ {} (@max .timestamp) ?: 0;

function days_from_now(days: integer) {
    return last_known_time() + (days * 24 * 60 * 60 * 1000);
}

last_known_time() is a solid all-purpose helper. It returns the most recent known timestamp in the blockchain. During an operation, it uses op_context.last_block_time; otherwise, it fetches the maximum timestamp from existing blocks. If no blocks exist yet (e.g., during initialization), it returns 0. This provides a safe and consistent way to get a reliable timestamp in any context.
days_from_now(days) takes the current time and adds n days to it, returning the result in milliseconds. Perfect for setting expiration dates.

Now don’t forget to import utils in oddly/module.rell:

import .utils;

And now let’s get back to our operation and drop in those require checks to make sure the input values stay within bounds.

operation create_event(question: text, expires_in_days: integer) {
    val account = auth.authenticate();

    require(
        question.size() >= utils.MIN_QUESTION_LENGTH and question.size() <= utils.MAX_QUESTION_LENGTH,
        "Question must be between 10 and 280 characters."
    );
    require(
        expires_in_days > utils.MIN_EXPIRATION_DAYS and expires_in_days < utils.MAX_EXPIRATION_DAYS,
        "Expiration period must be between 1 and 365 days."
    );
}

Next comes the time logic. We need to figure out exactly when the event is supposed to expire. Thanks to the days_from_now(expires_in_days) function we just built in utils, we can easily calculate a future timestamp by adding the number of days to the current block time. The result is a millisecond-based timestamp, which we’ll store in the expires_at field.

On the frontend, we’ll later convert it into a nice human-readable format like “May 20, 2025 at 1:00 PM”.

Now we pass everything to the function and here’s the final version of our operation:

operation create_event(question: text, expires_in_days: integer) {
    val account = auth.authenticate();

    require(
        question.size() >= utils.MIN_QUESTION_LENGTH and question.size() <= utils.MAX_QUESTION_LENGTH,
        "Question must be between 10 and 280 characters."
    );
    require(
        expires_in_days > utils.MIN_EXPIRATION_DAYS and expires_in_days < utils.MAX_EXPIRATION_DAYS,
        "Expiration period must be between 1 and 365 days."
    );

    val expires_at = utils.days_from_now(expires_in_days);
    create event ( creator = account, question, expires_at );
}

The final touch for today is to add a simple query that returns all events as they are. Later on, we’ll definitely enhance it with pagination, sorting, filtering by status (active, closed), and maybe even keyword search. But for now, the goal is just to fetch a full list of events for debugging.

So in oddly/queries.rell, let’s add:

query get_events(): list<event> {
    return event @* { };
}

Alright, let’s jump into testing — because without tests, we can’t really be sure that anything works the way it’s supposed to. First, in development.rell, fix the existing import and, for now, bring in everything we’ve created:

import oddly.*;

Then in tests/module.rell, add the ft_auth_operation_for import from FT4 to handle authentication inside the tests. The whole file should look like this:

@test module;

import development.*;

import lib.ft4.test.core.{ create_auth_descriptor, ft_auth_operation_for };
import lib.ft4.external.accounts.{ get_account_by_id };

Awesome. Below is a test suite that clearly checks whether everything works the way we intended. One positive case and four negative ones. The main point here is that we don’t just throw some data into create_event — we walk through the full flow: register an account, authenticate it, run the operation, and then make sure the result matches what we expect. One thing to highlight — notice how we always call ft_auth_operation_for before invoking create_event. Without that, the auth.authenticate() call in your operation just won’t work.

function test_create_event() {
    val alice = rell.test.keypairs.alice;

    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());
    rell.test.tx()
        .op(open_strategy.ras_open(auth_descriptor))
        .op(strategies.register_account())
        .sign(alice)
        .run();

    rell.test.tx()
        .op(ft_auth_operation_for(alice.pub))
        .op(create_event("Will CHR be $10 in a week?", 7))
        .sign(alice)
        .run();

    val events = get_events();

    assert_equals(events[0].creator.id, alice.pub.hash());
    assert_equals(events[0].question, "Will CHR be $10 in a week?");
    assert_true(events[0].created_at > 0);
    assert_equals(events[0].is_closed, false);
    assert_true(events[0].expires_at > events[0].created_at);
    assert_equals(events[0].result, result_values.UNRESOLVED);
}

function test_create_event_too_short_question_must_fail() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    rell.test.tx()
        .op(open_strategy.ras_open(auth_descriptor))
        .op(strategies.register_account())
        .sign(alice)
        .run();

    rell.test.tx()
        .op(ft_auth_operation_for(alice.pub))
        .op(create_event("Too short", 7))
        .sign(alice)
        .run_must_fail("Question must be between 10 and 280 characters.");
}

function test_create_event_too_long_question_must_fail() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    rell.test.tx()
        .op(open_strategy.ras_open(auth_descriptor))
        .op(strategies.register_account())
        .sign(alice)
        .run();

    val long_question = "A".repeat(300);

    rell.test.tx()
        .op(ft_auth_operation_for(alice.pub))
        .op(create_event(long_question, 7))
        .sign(alice)
        .run_must_fail("Question must be between 10 and 280 characters.");
}

function test_create_event_exceeds_max_expiration_must_fail() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    rell.test.tx()
        .op(open_strategy.ras_open(auth_descriptor))
        .op(strategies.register_account())
        .sign(alice)
        .run();

    rell.test.tx()
        .op(ft_auth_operation_for(alice.pub))
        .op(create_event("Will CHR be $100?", 400))
        .sign(alice)
        .run_must_fail("Expiration period must be between 1 and 365 days.");
}

function test_create_event_zero_days_must_fail() {
    val alice = rell.test.keypairs.alice;
    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());

    rell.test.tx()
        .op(open_strategy.ras_open(auth_descriptor))
        .op(strategies.register_account())
        .sign(alice)
        .run();

    rell.test.tx()
        .op(ft_auth_operation_for(alice.pub))
        .op(create_event("Will CHR reach $1 today?", 0))
        .sign(alice)
        .run_must_fail("Expiration period must be between 1 and 365 days.");
}

Nice, that’s a wrap — our basic Prediction Market just took its first breath. Here’s what we accomplished today:

✅ created the first entity
✅ implemented the event creation logic
✅ added validation for user input
✅ wrote a basic query to fetch all events
✅ covered it all with proper unit tests

Next time we’ll:

refactor the tests and clean up duplicate logic
add a new entity called bet where users can place predictions
expand get_events to include filtering

Let’s keep building.

👈 Previous step | 💻 GitHub repo | Next step 👉

Building a Prediction Market on Chromia | Step 2 — Adding Accounts and User Registration

Dmytro Zahumennov — Tue, 29 Apr 2025 10:23:05 +0000

Now let’s work on one of the core parts of any dapp — accounts. Accounts allow you to interact with the dapp, sign transactions, hold assets, send and receive tokens, and so on. So we need to add the ability to create accounts in our dapp, and for that we’ll use the FT4 library — it simplifies integration and takes care of everything I just mentioned.

FT4 supports multiple account strategies. We’ll use two of them:

For development — the open strategy. This one allows anyone to create accounts without restrictions, which will make our life easier during development.
For production — open strategy isn’t a great idea, since someone could spam the chain. So we’ll use at least the transfer open strategy. With this one, the user needs to make a transfer (e.g., 10 CHR) to create an account (we can configure the amount). Later, the user can use those tokens to create an event, for example. More details about FT4 strategies you can find here.

So, the first thing we do is go to the src directory and rename main.rell to development.rell. This helps us separate development and production environments — so we can use some functions and operations only during development to speed up the process. Then we create a new directory called oddly. Inside it, we create a file module.rell with a single line:

module;

This file declares the entire directory as a module, so we don’t need to add module; in every other file inside it. We’ll also keep all the imports here.

Next, let’s update the chromia.yml file. We’ll rename the blockchain and point it to the new main module. Later we’ll add a separate production blockchain with its own module.

blockchains:
  oddly_development:
    module: development
compile:
  rellVersion: 0.14.5
database:
  schema: schema_oddly
test:
  modules:
    - test

Now let’s install the FT4 library. To do that, we add the libs section to our config file:

blockchains:
  oddly_development:
    module: development
compile:
  rellVersion: 0.14.5
database:
  schema: schema_oddly
test:
  modules:
    - test
libs:
  ft4:
    registry: https://gitlab.com/chromaway/ft4-lib.git
    path: rell/src/lib/ft4
    tagOrBranch: v1.1.0r
    rid: x"FEEB0633698E7650D29DCCFE2996AD57CDC70AA3BDF770365C3D442D9DFC2A5E"
    insecure: false
  iccf:
    registry: https://gitlab.com/chromaway/core/directory-chain
    path: src/lib/iccf
    tagOrBranch: 1.87.0
    rid: x"9C359787B75927733034EA1CEE74EEC8829D2907E4FC94790B5E9ABE4396575D"
    insecure: false

And then we run:

chr install

The output looks something like this:

remote: Enumerating objects: 1776
remote: Counting objects: 100% (1776/1776)
remote: Compressing objects: 100% (1356/1356)
Receiving objects: 100% (1776/1776)
Resolving deltas: 100% (861/861)
Checking out files: 100% (614/614)
remote: Enumerating objects: 6445
remote: Counting objects: 100% (6445/6445)
remote: Compressing objects: 100% (2879/2879)
Receiving objects: 100% (6445/6445)
Resolving deltas: 100% (4797/4797)
Checking out files: 100% (464/464)

Boom — the library is installed. Now to complete the integration for the open strategy, all we need to do is import it. Let’s add the imports to development.rell and also import the whole oddly module for now. The file should look like this:

module;

import oddly;
import open_strategy: lib.ft4.core.accounts.strategies.open;
import strategies: lib.ft4.external.accounts.strategies;

That’s it. Time to test. First, rename the test folder to tests, and inside it, create a folder called development_tests. Inside that, create a module.rell file with this content:

@test module;

import development.*;

import lib.ft4.test.core.{ create_auth_descriptor };
import lib.ft4.external.accounts.{ get_account_by_id };

@test module; - declares the entire directory as a test module.

import lib.ft4.test.core.{ create_auth_descriptor }; - we need this import to create an auth descriptor for testing. Auth descriptors are a mechanism that defines the authorized key pairs and their associated permissions for interacting with accounts on the blockchain. More details you can find here.

import lib.ft4.external.accounts.{ get_account_by_id }; - query to check if the account exists after registration.

import development.*; - imports everything from the dev environment. This isn’t very safe, and it’s better to avoid such imports. We’ll fix it later.

Now let’s write a basic test case to check that account registration works. In src/tests/development_tests, create a file called account_test.rell and write next:

function test_account_creation() {
    val alice = rell.test.keypairs.alice;

    val auth_descriptor = create_auth_descriptor(alice.pub, ["A", "T"], null.to_gtv());
    rell.test.tx()
        .op(open_strategy.ras_open(auth_descriptor))
        .op(strategies.register_account()).sign(alice)
        .run();

    val alice_account_id = alice.pub.hash();
    val alice_account = get_account_by_id(alice_account_id);

    assert_not_null(alice_account);
}

Here we create a test keypair and auth descriptor for Alice’s account. Then we call two operations:

ras_open — an operation that initializes the open strategy.
register_account — an operation that registers the account.

Since the account ID is a hash of the public key (or EVM address, but we’ll get to that later), we use get_account_by_id to fetch the account and verify it with assert_not_null.

One more thing, we need to add an admin public key to chromia.yml. Even though we don’t need it for this test, FT4 requires it to run tests properly.

Let's open terminal and generate a keypair with:

chr keygen --file=".admin_keypair"

Copy the public key and paste it into the config like this:

blockchains:
  oddly_development:
    module: development
compile:
  rellVersion: 0.14.5
database:
  schema: schema_oddly
test:
  modules:
    - tests
  moduleArgs:
    lib.ft4.core.admin:
      admin_pubkey: x"03D57B4ED50601A3E331BA97D6CB9035D7FF90F016831FD15D450596BB4EFE78B1"
libs:
  ft4:
    registry: https://gitlab.com/chromaway/ft4-lib.git
    path: rell/src/lib/ft4
    tagOrBranch: v1.1.0r
    rid: x"FEEB0633698E7650D29DCCFE2996AD57CDC70AA3BDF770365C3D442D9DFC2A5E"
    insecure: false
  iccf:
    registry: https://gitlab.com/chromaway/core/directory-chain
    path: src/lib/iccf
    tagOrBranch: 1.87.0
    rid: x"9C359787B75927733034EA1CEE74EEC8829D2907E4FC94790B5E9ABE4396575D"
    insecure: false

Let’s also check that the structure of our project looks correct:

And now we can run the test:

chr test

And boom - everything works! The account was created successfully 🎉 You should see something like this:

====================Running unit tests====================
TEST: tests.development_tests:test_account_creation
OK: tests.development_tests:test_account_creation (0.871s)

------------------------------------------------------------------------
TEST RESULTS:

OK tests.development_tests:test_account_creation (0.871s)

SUMMARY: 0 FAILED / 1 PASSED / 1 TOTAL (0.871s)

***** OK *****

Accounts are up and running! Next, we’ll start shaping the core of our prediction market — building entities and operations one by one. Let’s keep pushing forward! 🔥

👈 Previous step | 💻 GitHub repo | Next step 👉

Building a Prediction Market on Chromia | Step 1 — Project Setup

Dmytro Zahumennov — Mon, 28 Apr 2025 10:14:42 +0000

Hi! I’m Dmytro, a Dev Advocate at Chromia. Recently, I’ve been feeling a strong urge to start building my own fun side projects, and Chromia’s infrastructure fits perfectly for that. No gas fees, a simple and compact relational programming language (Rell), access to a public testnet, good documentation, and a learning platform — all of this gives us the chance to build and launch our first MVP pretty fast. To start, we’ll keep things very simple and focus only on the minimum functionality. Then step-by-step, we’ll add more features and develop the dapp further. I think with time, we could even integrate some AI features into the project.

So, let’s build a Prediction Market on Chromia! The idea is: a user can create a simple event like “Will Chromia hit $10 tomorrow?” and allow others to vote “Yes” or “No” using our own LOL token. Here’s the rough functionality for the MVP (Phase 1):

Create events
Stake LOL tokens to vote
Manual resolution of event outcomes (admin)
Distribute rewards among winners
Very simple UI: a homepage with a list of active markets
User profiles with voting history
Deploy dapp on Chromia testnet
Open access for early testers

Let’s get started with the environment setup! I’m working on MacOS, so I’ll explain things from that perspective. If you are using a different system, you can find instructions on installing and setting everything up in the Chromia documentation and learning platform.

Chromia is a relational blockchain — it stores data in a relational format, which makes it very unique and developer-friendly. So first, we need to setup PostgreSQL:

brew install postgresql@16

brew services start postgresql@16

createuser -s postgres

psql -U postgres -c "CREATE DATABASE postchain WITH TEMPLATE = template0 LC_COLLATE = 'C.UTF-8' LC_CTYPE = 'C.UTF-8' ENCODING 'UTF-8';" -c "CREATE ROLE postchain LOGIN ENCRYPTED PASSWORD 'postchain'; GRANT ALL ON DATABASE postchain TO postchain;"

Now we need the Chromia CLI, which will make it much easier to deploy, test, and launch our dapp to the testnet.
Install it using:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

brew tap chromia/core https://gitlab.com/chromaway/core-tools/homebrew-chromia.git

brew install chromia/core/chr

Check that everything installed correctly:

chr --version

Without thinking too much about the name, let’s call our project Oddly, and create it:

chr create-rell-dapp oddly --template=plain

Open the project in Cursor (or your preferred editor) — and boom, the basic template is ready!

I won’t dive into all the details just yet, but let’s quickly review the project structure:

In the src directory, you’ll find the main module main.rell, which contains the core logic of the dapp. Over time, we’ll expand it and break it into multiple files for better structure.
The tests folder is pretty self-explanatory.
Files like .rell_format and .rell_lint are configuration files for formatting and linting — we’ll leave them with default settings for now.
The key file is chromia.yml, which handles all the dapp configurations. We’ll refer to it often, and I’ll explain the important parts as we go.

My suggestion: don’t get stuck in the tiny details at this point. Let’s focus on building a working project first — the deep understanding will come naturally through the process.

Let’s keep moving! 🚀

💻 GitHub repo | Next step 👉