---

Cairo Two Fer Explained: Master Option & Pattern Matching From Zero

The Cairo 'Two Fer' problem is a foundational exercise for mastering conditional logic through the Option<ByteArray> enum and pattern matching. It involves creating a function that returns a personalized string "One for [name], one for me." if a name is provided, or a generic "One for you, one for me." if it is not.

Imagine walking into your favorite bakery. A sign catches your eye: "Two-fer One Holiday Special!" You buy a delicious cookie, and thanks to the deal, you get a second one for free. As you turn to leave, you see someone else in line. You have a choice: if you know their name, say, "Alice," you can offer, "One for Alice, one for me." But if they're a stranger, a simple, "One for you, one for me," does the trick. This simple, real-world decision is the perfect analogy for one of the most critical concepts in modern programming: handling the presence or absence of data safely. In Cairo, this isn't just a good practice; it's a core principle enforced by the compiler to build robust and secure smart contracts.

Many developers coming from languages like Python or JavaScript are used to dealing with null, None, or undefined, which can often lead to unexpected runtime errors. Cairo, borrowing from Rust's philosophy, provides a powerful and safe alternative: the Option enum. This kodikra module will guide you through this fundamental concept, transforming a simple string-formatting task into a deep understanding of Cairo's type safety, pattern matching, and idiomatic coding practices. By the end, you'll not only solve the "Two Fer" problem but also grasp a pattern that is essential for writing professional-grade StarkNet contracts.

---

What is the "Two Fer" Problem in Cairo?

At its core, the "Two Fer" problem, as presented in the kodikra learning path, is a challenge in conditional string generation. The goal is to implement a single function, let's call it response, that accepts one argument: a person's name. The twist is that the name is optional—it might be provided, or it might not.

The function's behavior must change based on whether a name is present:

• If a name is given (e.g., "Do-yun"), the function must return the string "One for Do-yun, one for me.".
• If no name is given, the function must default to using the word "you", returning the string "One for you, one for me.".

To make this concrete, here is a table of expected inputs and their corresponding outputs:

Input Name	Expected Dialogue Output
Alice	One for Alice, one for me.
Bohdan	One for Bohdan, one for me.
(No Name Provided)	One for you, one for me.
Zaphod	One for Zaphod, one for me.

While this seems like a simple if-else statement, its true purpose in the Cairo curriculum is to introduce you to the idiomatic way of handling optional values. Instead of checking for a null value, you will learn to use Cairo's powerful Option enum and match expressions to handle these two states in a way that is both elegant and guaranteed by the compiler to be free of null-related errors.

---

Why This is a Foundational Challenge for StarkNet Developers

The "Two Fer" problem is far more than a beginner's exercise in string manipulation; it's a deliberate introduction to a core pillar of Cairo and Rust's design philosophy: compile-time safety and explicitness. Understanding this challenge lays the groundwork for writing secure and reliable smart contracts on StarkNet.

Introducing the `Option` Enum: Cairo's Answer to `null`

In many programming languages, the absence of a value is represented by a special keyword like null, nil, or None. This approach is notoriously problematic and has been called "the billion-dollar mistake" by its inventor, Tony Hoare. Why? Because it forces the developer to remember to check for null everywhere. Forgetting even one check can lead to a runtime error that crashes the program or, in the context of a smart contract, creates a critical vulnerability.

Cairo solves this by completely eliminating the concept of null. Instead, it uses a generic enumeration (or enum) called Option<T>. An enum is a type that can be one of several possible variants. The Option enum is defined with two variants:

• Some(T): This variant indicates that a value of type T is present. The value itself is wrapped inside Some. For our problem, this would be Some(ByteArray).
• None: This variant indicates the absence of a value. It's an explicit, typed way of saying "there is nothing here."

By using Option<ByteArray> for the name, the function signature itself forces you to handle both possibilities. The Cairo compiler will refuse to compile your code if you try to use the value inside a Some without first explicitly handling the None case. This shifts error detection from unpredictable runtime crashes to predictable compile-time errors, which is infinitely more desirable, especially in the high-stakes world of blockchain.

The Power of Pattern Matching with `match`

To work with enums like Option, Cairo provides a powerful control flow construct called match. A match expression lets you compare a value against a series of patterns and execute code based on which pattern matches. For an Option, the patterns are naturally its two variants: Some(value) and None.

The match statement is exhaustive. This means you must provide a course of action (an "arm") for every possible variant of the enum. The compiler enforces this, guaranteeing that you have considered all possibilities. For "Two Fer," this means you are forced to write code for the "name is present" case and the "name is absent" case. You literally cannot forget.

This is the core lesson: Cairo guides you toward writing correct, robust code by making invalid states unrepresentable in the type system and forcing you to handle all logical branches.

---

How to Solve the Problem: A Step-by-Step Code Walkthrough

Let's dissect the idiomatic Cairo solution for the "Two Fer" problem. We will analyze the function signature, the control flow, and the string formatting to understand how each part contributes to a safe and elegant solution.

The Final Code

Here is the complete, concise, and idiomatic solution from the kodikra.com module:

pub fn response(name: Option<ByteArray>) -> ByteArray {
    match name {
        Option::Some(n) => format!("One for {n}, one for me."),
        Option::None => "One for you, one for me.",
    }
}

This small block of code is dense with important Cairo concepts. Let's break it down piece by piece.

Line-by-Line Analysis

1. The Function Signature

pub fn response(name: Option<ByteArray>) -> ByteArray {

• pub fn response: This declares a public (pub) function named response. Public visibility means it can be called from other modules or contracts.
• (name: Option<ByteArray>): This defines the function's single parameter.
  • name: The name of the parameter.
  • Option<ByteArray>: The type of the parameter. This is the crucial part. It explicitly states that name is not a simple ByteArray. Instead, it is an Option that might contain a ByteArray. This signature immediately signals to any developer using this function that they must account for the possibility of a missing name.
• -> ByteArray: This specifies the return type. The function is guaranteed to return a ByteArray, which is Cairo's primary type for handling dynamic strings.

2. The `match` Expression

    match name {

This is the start of the pattern matching block. We are telling the compiler that we want to inspect the value of the name variable (which is of type Option<ByteArray>) and execute different code based on its structure.

Here is a visual representation of the logical flow that the `match` statement implements:

    ● Start with `name: Option<ByteArray>`
    │
    ▼
  ┌─────────────────┐
  │   `match name`  │
  └────────┬────────┘
           │
           ▼
  ◆ Is `name` Some(value) or None?
   ╱                           ╲
  ╱                             ╲
Yes (It's `Some(n)`)          No (It's `None`)
  │                              │
  ▼                              ▼
┌──────────────────────────┐   ┌──────────────────────────┐
│ Execute `Some` arm       │   │ Execute `None` arm       │
│ `format!("One for..")`    │   │ `"One for you..."`         │
└────────────┬─────────────┘   └────────────┬─────────────┘
             │                              │
             └──────────────┬───────────────┘
                            │
                            ▼
                  ● Return the resulting `ByteArray`

3. The `Some` Arm

        Option::Some(n) => format!("One for {n}, one for me."),

• Option::Some(n): This is the first pattern. It checks: "Is the value of name the Some variant of the Option enum?" If it is, the code does something brilliant: it unpacks the value held inside Some and binds it to a new variable, n. In this scope, n is a guaranteed-to-exist ByteArray.
• =>: The "fat arrow" separates the pattern from the code that will be executed if the pattern matches.
• format!("One for {n}, one for me."): This is the code to execute. The format! macro is Cairo's standard way to perform string interpolation. It constructs a new ByteArray by taking the template string and replacing {n} with the value of our unpacked variable n. The comma at the end signifies that this is the value the entire match block will return if this arm is chosen.

4. The `None` Arm

        Option::None => "One for you, one for me.",

• Option::None: This is the second pattern. It simply checks: "Is the value of name the None variant?"
• =>: The fat arrow, again.
• "One for you, one for me.": This is the code for the `None` case. It's a simple string literal. Cairo automatically infers that this should be converted into a ByteArray to match the function's return type. This is the value the match block returns if the input was None.

Because `match` expressions are expressions (meaning they evaluate to a value), the value of the chosen arm becomes the return value of the entire function. This makes the code extremely concise and readable, without needing an explicit return keyword.

---

Where These Concepts Are Used in Real-World StarkNet Contracts

The pattern of using Option and match is not just an academic exercise; it is ubiquitous in professional StarkNet development. It provides the safety and predictability required for financial applications and decentralized systems. Here are a few real-world scenarios where you'll encounter this exact pattern.

1. Querying Storage Mappings

In Cairo smart contracts, you often use a LegacyMap or the newer StorageMap to associate data with keys, like mapping a user's address to their token balance.

// A simplified mapping of user addresses to their profile names
#[storage]
struct Storage {
    profile_names: LegacyMap<ContractAddress, ByteArray>,
}

When you try to read from this map using profile_names.read(user_address), what happens if the user has never set a profile name? The call doesn't crash. Instead, it returns an Option<ByteArray>! It will be Some(name) if a name exists, and None if it doesn't. You would then use a match statement to handle both cases gracefully, perhaps displaying a default name if none is set.

2. Handling Optional Function Parameters

Imagine a function in an NFT contract that allows a user to mint an NFT and optionally assign a resolver (a contract that can manage it).

fn mint(recipient: ContractAddress, resolver: Option<ContractAddress>) {
    // ... core minting logic ...
    match resolver {
        Option::Some(addr) => {
            // Logic to set the custom resolver
            set_resolver_for_token(token_id, addr);
        },
        Option::None => {
            // Logic to set the owner as the default resolver
            set_resolver_for_token(token_id, recipient);
        }
    }
}

This makes the contract's interface flexible while ensuring that every logical path is explicitly handled, preventing unexpected states.

3. Parsing Return Data from External Contract Calls

When your contract calls another contract, the call might fail or the function might be designed to return an optional value. The return data often needs to be deserialized, and this process can fail if the data is malformed. A safe deserialization function would return an Option<MyCustomStruct>, allowing your contract to handle the success case (Some(data)) and the failure-to-parse case (None) without panicking.

Here is an ASCII diagram illustrating this common smart contract pattern:

    ● User calls `get_profile(address)`
    │
    ▼
  ┌───────────────────────────┐
  │ Read `profile_names` map  │
  └────────────┬──────────────┘
               │
               ▼
  ◆ Does a name exist for the address?
   ╱                              ╲
  ╱                                ╲
Yes (`Some(name)`)                  No (`None`)
  │                                 │
  ▼                                 ▼
┌──────────────────┐              ┌──────────────────────┐
│ Return the name  │              │ Return default value │
│ (e.g., "Alice")  │              │ (e.g., "Unnamed")    │
└──────────────────┘              └──────────────────────┘

---

Pros and Cons: `match` vs. Other Approaches

While match is the most idiomatic and often the best tool for handling Option, Cairo (like Rust) provides other convenient methods. Understanding their trade-offs is key to becoming a proficient developer.

Approach	Pros	Cons
match statement	Exhaustive: Compiler guarantees all cases are handled. Extremely Clear: Explicitly shows the logic for both Some and None. Powerful: Can match on complex nested data structures, not just simple enums.	Can be slightly more verbose for very simple cases where you only care about one variant.
if let statement	Concise: Excellent when you only care about the Some case and want to do nothing for None. Readable for single-case logic.	Not exhaustive by default; requires an else block to handle the None case, which can be forgotten. Less suitable when both variants have complex, distinct logic.
unwrap_or method	Very Concise: The shortest way to provide a default value. name.unwrap_or("you"). Perfect for when the logic is simply "use the value if it's there, otherwise use this default".	Less Flexible: Only works for providing a simple default value. Cannot execute different blocks of code. The default value is always evaluated, which could be inefficient if it's a function call. (Use unwrap_or_else for that).

For the "Two Fer" problem, the match statement is the most instructive and clearest approach. However, an experienced developer might also solve it like this using unwrap_or, which is more concise but hides the underlying branching logic:

// An alternative, more concise solution
pub fn response_concise(name: Option<ByteArray>) -> ByteArray {
    // If name is Some(n), n is used. If None, the default "you" is used.
    let person = name.unwrap_or("you".try_into().unwrap());
    format!("One for {person}, one for me.")
}

This alternative demonstrates flexibility but reinforces why the match-based solution is taught first in the kodikra Cairo Learning Roadmap: it makes the control flow explicit and builds a stronger foundational understanding.

---

Frequently Asked Questions (FAQ)

1. What is a `ByteArray` in Cairo?

A ByteArray is a new, flexible type introduced in Cairo for handling dynamic, heap-allocated strings. It's designed to be more efficient and developer-friendly than the older `felt252` short strings, especially for strings of unknown or variable length, making it ideal for things like names, descriptions, and URIs in smart contracts.

2. Why not just use an empty string ("") instead of `Option`?

Using a "sentinel value" like an empty string to represent the absence of data is a common but flawed pattern. It blurs the line between "a user whose name is an empty string" and "a user for whom we have no name." Using Option is more explicit and semantically correct. None means "no value provided," which is distinct from Some(""), which means "a value was provided, and it was an empty string." This precision prevents logical bugs.

3. Can I use an `if/else` statement instead of `match` for this problem?

Yes, you can replicate the logic using methods on Option like is_some() and unwrap(), but it is strongly discouraged. This approach is more verbose and less safe. For example:

if name.is_some() {
    format!("One for {}, one for me.", name.unwrap())
} else {
    "One for you, one for me.".into()
}

This is less idiomatic, and the call to unwrap() can panic if used incorrectly without the check. The match statement handles the check and the unpacking in one safe, atomic operation.

4. What is the difference between `Option` and `Result` in Cairo?

Both are enums that represent outcomes, but they are used for different scenarios. Use Option when a value can be absent, and this is a normal, expected situation (like a missing profile name). Use Result<T, E> when an operation can succeed (returning Ok(T)) or fail (returning Err(E)). `Result` is for handling recoverable errors, like a failed network call or an invalid input, where you want to provide information about the error E.

5. How does Cairo's `Option` compare to `null` in other languages?

Cairo's Option is a type-safe wrapper, whereas null is a value that can sneak into any reference type, breaking type safety. With Option, the type system forces you to handle the `None` case. With null, the burden is on the programmer to remember to check for it, and the penalty for forgetting is a runtime error. This makes Option fundamentally safer.

6. Is the `format!` macro expensive in terms of gas on StarkNet?

String manipulation, including formatting, can be gas-intensive on any blockchain because it involves memory allocation and processing. While format! is highly optimized, developers should be mindful. For on-chain logic, it's often better to work with fixed-size data like `felt252` or integers if possible. Use `ByteArray` and `format!` when string data is truly necessary, such as for emitting events or storing human-readable metadata.

7. Where can I learn more about enums and pattern matching in Cairo?

The best place to continue your journey is by exploring the official Cairo Book and diving into more challenges in the kodikra curriculum. You can also see the complete Cairo guide on our platform, which covers these topics in greater detail with more advanced examples and projects.

---

Conclusion: Beyond "Two Fer"

The "Two Fer" challenge, while simple on the surface, perfectly encapsulates the philosophy of safety and explicitness that defines modern systems programming and is absolutely critical for smart contract development. By completing this module, you have done more than just format a string; you have engaged with two of Cairo's most powerful features: the Option enum and the match expression.

You have learned how Cairo eradicates an entire class of runtime errors by eliminating null and forcing all possibilities to be handled at compile time. This principle of leveraging the type system to write more robust, predictable, and secure code is a theme you will see again and again as you progress. Mastering this pattern is a significant step toward thinking like a true Cairo developer and building applications on StarkNet that are not only functional but also resilient.

Technology Disclaimer: All code snippets and explanations are based on Cairo 2.6.x and the Scarb 2.6.x toolchain. The Cairo language is evolving rapidly; always consult the official documentation for the latest syntax and features.

Ready to tackle the next challenge? Explore our comprehensive Cairo Learning Roadmap to continue building your skills.

---

Published by Kodikra — Your trusted Cairo learning resource.