Brand Bible v1.2.0 - 🔴 (LIVE)

SODAX is an execution and liquidity system that enables applications to perform cross-network financial actions, without owning cross-network infrastructure.

Today, SODAX supports live cross-network swaps and money market access, coordinating execution across networks where liquidity, pricing, and execution environments differ.

It provides:

• A developer SDK for building cross-network execution flows
• A retail-facing surface where those actions feel understandable and outcome-focused.

SODAX is not a bridge or a messaging standard. It is an execution coordination system designed to behave predictably under real-world constraints.

To make cross-network execution usable at scale.

As decentralized finance expands across multiple networks, execution complexity increasingly limits what builders can ship and what users can trust. SODAX exists to absorb that complexity into infrastructure, so applications can focus on outcomes rather than coordination across networks.

SODAX helps applications deliver cross-network outcomes without forcing them to become cross-network infrastructure companies.

We do this by coordinating execution and liquidity across networks in a way that is:

• Honest about constraints
• Grounded in DeFi-native participation,
• Designed for real usage, not idealized condition

We do not promise instant execution or perfect outcomes. We promise a system designed to behave predictably and recoverably as network conditions change.

These values describe how SODAX behaves, they are not just aspirational slogans.

1. Outcome-oriented

We optimize for whether users reach their intended outcome across networks, not for isolated metrics like speed or theoretical price at the expense of completion.

2. Builder-first, not builder-blind

We abstract cross-network execution complexity without hiding economic reality. Builders retain control, responsibility, and flexibility.

3. Honest about constraints

Asynchronous execution, partial failure, and recovery paths are realities of multi-network systems, not marketing problems to hide.

4. Participation by design

SODAX is designed so that liquidity can be supplied by users, coordinated centrally, and combined with protocol-owned and external liquidity sources to support reliable cross-network execution.

The protocol takes responsibility for coordinating liquidity where markets do not exist, while allowing users to participate economically where appropriate.

5. Long-term credibility

We avoid claims that cannot be defended over time. Trust compounds; expectation debt does not.

SODAX’s personality reflects serious infrastructure built by people who understand the stakes of cross-network execution, and respect their users.

SODAX is:

• Clear, not flashy
• Confident, not absolute
• Technical, but not exclusionary
• Calm under complexity
• Pragmatic about tradeoffs

SODAX is not:

• Hype-driven
• Ideological
• Dismissive of failure modes
• Casual with claims
• Obscure for the sake of sounding advanced

This balance allows SODAX to speak credibly to engineers, partners, and ecosystem leaders while remaining approachable to non-specialists.

Execution coordination over asset movement.

SODAX is built on the idea that moving assets across networks is no longer the hard part, but reliably delivering the intended outcome is.

Instead of treating cross-network activity as a transfer problem, SODAX treats it as an execution problem: one that must account for liquidity availability, asynchronous behavior, and real-world failure modes across multiple networks.

This idea unifies:

• the SDK experience for builders, and
• the invisible infrastructure that supports user-facing applications.

SODAX coordinates execution when the path across networks is non-trivial, constrained, or subject to change.

Decentralized finance now operates across many networks with different execution environments, liquidity profiles, and constraints.

While moving assets between networks has become increasingly possible, reliably executing meaningful financial actions across them has not.

As a result:

• Users reach assets on destination networks without the liquidity, gas, or context needed to act
• Builders face growing execution complexity and operational risk
• Liquidity remains fragmented and difficult to use where it already exists

In practice, this means that even when assets can move between networks successfully, users and applications often fail to reach the broader outcome they intended.

Most existing solutions optimize parts of the problem, transfer, messaging, routing, or pricing, but do not coordinate execution end to end.

SODAX exists in this gap.

SODAX is a cross-network execution and liquidity system.

It enables applications to coordinate complex financial actions across multiple networks, without requiring them to build or maintain cross-network execution infrastructure themselves.

SODAX is:

• An execution coordination system
• A liquidity-aware infrastructure layer
• A developer-facing SDK surface

SODAX is not:

• A bridge
• A messaging standard
• A single-network route
• A black-box abstraction that hides economic reality

When describing SODAX, behavior matters more than labels. The system should be explained by what it enables and how it behaves, not by borrowed category names.

The core problem

Cross-network systems can move assets, but they do not reliably deliver intended outcomes.

An intended outcome is not a transaction or a quote. It is when:

• A user reaches the asset, position, or liquidity they intended, in a usable context
• Execution completes or fails in a recoverable and understandable way
• Trust in the system is preserved

Today, this outcome problem persists because execution across networks is:

• Asynchronous by nature
• Dependent on fragmented liquidity
• Exposed to multiple failure modes

Why this matters

• For builders: cross-network support slows product velocity and increases operational burden.
• For users: cross-network actions feel fragile, confusing, and unpredictable.

SODAX exists to make cross-network execution more predictable, composable, and usable at scale.

SODAX is an execution coordination system that helps applications deliver cross-network financial outcomes, without owning cross-network infrastructure.

It coordinates liquidity and execution across networks under real-world constraints, allowing builders to ship multi-network actions while retaining control over user experience and economic decisions.

This positioning deliberately avoids:

• Speed absolutism
• Guarantees
• Claims of “solving” cross-network complexity

SODAX serves two primary B2B customer profiles and one indirect B2C audience.

SDK Partners

Applications that integrate the SODAX SDK to enable cross-network actions for their users. Four sub-types exist based on product surface:

• Wallet Apps
• DEXs, Routing, and Aggregators
• Money Markets, Lending, and Yield protocols
• Yield Strategy, Vault, and Capital Management platforms

They use SODAX to ship cross-network functionality without building or maintaining execution infrastructure.

Networks

L1 and L2 networks that connect to SODAX as spokes to gain access to cross-network liquidity and execution flow. They use SODAX to increase the utility and connectivity of their network without building bilateral bridges.

B2C: End users of SODAX-powered applications

• Users swapping assets across networks
• Users accessing liquidity, yield, or credit
• Users who want to complete financial actions without understanding network mechanics

SODAX should remain mostly invisible to this audience. Trust is owned by the application, not the infrastructure beneath it.

These pillars anchor all SODAX communication. Every external message should map back to at least one of them.

1. Execution coordination

SODAX coordinates execution outcomes across networks, rather than treating cross-network activity as a simple transfer problem.

2. Outcome-oriented design

The system prioritizes intended outcomes under real constraints, not speed or theoretical pricing in isolation.

3. Builder control

SODAX abstracts execution complexity while keeping builders in control of UX and economic decisions.

4. Explicit execution reality

Asynchronous execution and failure modes are acknowledged, surfaced clearly, and handled deliberately, not hidden.

For SDK Partners

• Enable cross-network execution through a single SDK integration
• Reduce infrastructure burden without losing UX or economic control
• Access liquidity across networks without managing fragmented pools
• Support alternative execution paths when network or liquidity conditions change
• Ship faster without becoming a cross-network infrastructure team

For Networks

• Gain cross-network connectivity without building bilateral bridge infrastructure
• Attract volume and users from other networks through SODAX execution flow
• Benefit from hub-and-spoke architecture that routes liquidity through established corridors

For B2C End Users (Indirect)

• Reduced friction in reaching the intended outcome
• Less exposure to network mechanics
• Clearer behavior when execution succeeds or fails
• More recoverable flows, rather than silent breakage

SODAX does not position itself as a consumer brand first. It enables consumer trust through infrastructure behavior.

SODAX is differentiated by how it coordinates execution across networks under real conditions, rather than by optimizing isolated components in abstraction.

Where many cross-network solutions focus on transferring assets, passing messages, or optimizing individual routes, SODAX focuses on how execution behaves end to end when liquidity, timing, and network conditions change.

In practice, this means:

• Execution is coordinated across multiple liquidity domains
• Alternative paths can be used when direct routes are insufficient
• Failure modes are handled explicitly rather than hidden

SODAX is designed to work with existing infrastructure, coordinating execution across networks rather than replacing the systems that already exist.

The following proof points demonstrate how SODAX’s positioning is grounded in production behavior today, while remaining extensible as capabilities evolve.

Live cross-network execution in production

SODAX supports live cross-network swaps and money market access, coordinating execution across networks where liquidity, pricing, and execution environments differ.

This validates the system’s ability to operate under real conditions, not just simulated or single-network environments.

Unified execution logic across liquidity domains

Execution is coordinated across multiple liquidity domains, including local network liquidity and centrally coordinated liquidity mechanisms.

This allows applications to access liquidity where it already exists, without requiring builders to mirror balances or manage fragmented pools manually.

Explicit handling of asynchronous execution

SODAX is designed around the realities of asynchronous cross-network execution.

Rather than assuming atomic completion, the system accounts for partial completion, delayed finality, and conditional execution paths, and exposes this behavior clearly to integrators.

Solver-driven execution with builder control

Execution decisions are handled by solver logic that optimizes for outcome completion under current conditions, while preserving builder-defined constraints and economic intent.

Builders retain control over UX, pricing, and risk parameters, rather than delegating those decisions to opaque routing logic.

Extensible execution model

While current production use cases focus on swaps and money market access, the execution model is designed to support more complex cross-network actions over time.

This extensibility is architectural, not speculative, and does not require a redesign of the core coordination model as new execution patterns are introduced.

When communicating about SODAX, we explicitly avoid:

• instant or guaranteed execution claims
• “solved cross-network” language
• black-box abstraction framing
• standards replacement narratives

SODAX is positioned as serious infrastructure, designed to behave predictably under real conditions, not as a shortcut around them.

SODAX should sound like:

1) Infra-serious

We speak with technical maturity and restraint. We avoid hype, absolutes, and empty claims.

2) Clear and welcoming

We make advanced concepts understandable without talking down to anyone. We define terms once, then keep moving.

3) Calm under complexity

We acknowledge constraints and tradeoffs. We focus on predictable behavior under real conditions, not idealized promises.

Use these principles in any SODAX communication.

Be specific

Prefer concrete terms over vague ones. Say what is being coordinated, what is being abstracted, and what remains true under constraints.

Be honest

Do not imply guarantees. Avoid “solved cross-network” language. When something is conditional, say so.

Be readable

Short sentences. Active voice. One idea per paragraph. Explain the outcome before the mechanism.

Be complementary

SODAX is designed to work with existing ecosystems and infrastructure. Avoid replacement narratives.

Be consistent

Prefer “network” over “chain”. Use the same core terms across channels.

Use sentence case for titles

Write titles and headings as a standard sentence but omit the period at the end. Only capitalize the first word and proper nouns.

B2B communication should be:

Direct and architectural

Talk in terms of responsibilities, constraints, and integration surfaces.

Outcome-led, then technical

Start with what the builder can enable. Then explain how the system behaves, including constraints.

Respectfully precise

Avoid marketing adjectives. Let clarity do the persuasion.

Default vocabulary

• execution coordination
• intended outcomes
• liquidity domains
• asynchronous execution
• constraints and failure modes
• builder control

B2C communication should be:

Simple and reassuring

Users care about completing actions, not infrastructure details.

Focused on what happens next

Explain what to expect, what success looks like, and what to do if something fails.

Avoid protocol theatre

Do not overwhelm users with mechanics. Only surface details when it helps trust and clarity.

Default vocabulary

• swap
• earn yield
• borrow
• available balance
• status updates
• clear next steps

Do

• Lead with the intended outcome, then explain how SODAX supports it
• Use “network” consistently
• Acknowledge constraints in a calm, matter-of-fact way
• Use language that builders can repeat to their teams and partners
• Keep claims defensible over time

Don’t

• Claim instant, guaranteed, or risk-free execution
• Say or imply “cross-network is solved”
• Use black-box framing like “we hide all complexity”
• Position SODAX as a replacement for standards or existing infrastructure
• Over-index on speed or best price claims without context

Use these as patterns, not scripts.

B2B one-liner

SODAX coordinates cross-network execution so builders can deliver intended outcomes under real conditions.

B2B short paragraph

SODAX helps applications support cross-network swaps and money market access without becoming cross-network infrastructure teams. It coordinates execution behavior across networks and liquidity domains, handles asynchronous reality explicitly, and preserves builder control over UX and economic intent.

B2C one-liner

Swap, earn, and borrow across networks, without getting stuck in the details.

B2C reassurance

Cross-network execution can take time and conditions can change. We show clear status updates and what to do next, so you always know where you stand.

• Primary logo lockup

1. Symbol + SODAX wordmark in horizontal lockup
2. Default for web, product UI, and marketing
• Secondary / compact versions

1. For app icons, small UI display, favicons
• Stacked lockup

1. Centered symbol above wordmark for narrow or vertical layouts
• Light vs dark background usage
• Light backgrounds: Cherry soda wordmark, yellow dark soda symbol

• Dark backgrounds: White wordmark, yellow soda symbol

• Mid-tone backgrounds: White wordmark and symbol
• Fully branded background: White wordmark, yellow soda symbol, cherry red background

• Space rules: Minimum clear space = diameter of the symbol. No text, UI elements, or edges may enter this zone
• Minimum digital size: Full lockup 100px width minimum; Symbol-only 24px minimum
• Logo Scale Guidance: The logo should typically be presented at a restrained, elegant size. Oversized use is reserved for intentional design statements only.
• Incorrect usage: Do not recolor outside defined palette, distort, rotate, animate, add shadows/gradients/outlines, or place on low-contrast or noisy backgrounds

• Primary brand colors (brand recognition)
• Cherry soda — #A55C55
• Yellow dark — #ECC100
• Selected secondary and neutral colors (structure, hierarchy, balance)
• Cherry bright — #CC9E9A
• Cherry brighter — #E3BEBB
• Yellow soda — #FFD92F
• Espresso — #483534
• Clay — #8E7E7D
• Clay light — #B9ACAB
• Subtle shades (used mostly as clear backgrounds)
• Cream white — #EDE6E6
• Almost white — #F8F3F3
• Vibrant white — #F9F7F5

Usage guidance

• Yellow soda accents leads emphasis and calls to action
• Cherry soda used as backgrounds in promotional or heavily branded applications
• Espresso or creams in business development applications
• Whites and creams dominate layout surfaces and user interfaces

Primary typeface: Inter

• Hierarchy rules
• Titles / headlines: Inter Black (uppercase or title case allowed)
• Body text: Inter Regular
• UI labels: Inter Regular / Medium

Accent / playful type: Shrikhand

• Used sparingly for key CTAs or playful emphasis
• Must always be lowercase (unless critical exceptions)
• 3-4 words maximum, never for long-form text

Usage by context

• Product & web UI: Inter only (clarity-first), shrikhand is used with caution
• Marketing moments: Inter + controlled Shrikhand accents
• Documentation: Inter only

Readability: Comfortable line-height for body copy, avoid tight tracking, prioritize clarity over personality in dense content

• Line-based generic icons with consistent stroke weight
• Avoid decorative icons
• Icons never replace text in critical flows

Principle: Bold brand when needed, calm layouts for products. Layouts should create trust first, personality second.

• Marketing moments stand out with bold color combinations

• UIs and websites tune down branding presence, prioritizing clear and roomy layouts

Rhythm: Fast, snappy pacing for short attention spans. Continuous micro-movement creates attention without chaos. Deceleration exists but never reaches zero during trap moments.

• Business or informational applications focus on clarity and trust, not personality

Grid & structure: Simple, predictable grids with centered or clearly anchored compositions for authority

Spacing: Generous spacing by default. "Roomy" layouts reduce cognitive load and increase trust. Fewer elements, bigger hierarchy.

Cards and containers: Medium rounded corners, flat or near-flat elevation, clear separation between content and decoration

Hierarchy: Extreme hierarchy is allowed and encouraged when density permits. One dominant element per screen. Supporting information should feel secondary at a glance.

Brand elements must never compete with content clarity.

Motion acts as a trap, then resolves: continuous tension → release → reset.

Principles

• First ~3 seconds should never feel static
• No true full-stop frames during motion
• Energy is maintained through curves, not speed alone

Rhythm: Fast, snappy pacing for short attention spans. Continuous micro-movement creates attention without chaos. Deceleration exists but never reaches zero during trap moments.

Timing & easing: Elements don't appear or disappear in linear sequence, but in uneven steps. Aggressive, well-shaped f-curves over linear or smooth timing. Ease-in/ease-out applies, but with momentum preserved.

1. Just a few words at the same time
2. Comfortable usage of negative space
3. Big margins encouraged to keep eye scanning in central area

Avoid: Static intro frames, motion pauses that feel "dead", playful bounce on logos or financial data

Motion should feel alive before it's understood, then get out of the way.

Accessibility at SODAX is intentional, not neutral. We respect accessibility standards while deliberately using hierarchy to reduce cognitive load and surface what matters most.

Typography

• Body text meets minimum readable size and line-height
• Critical information (balances, APRs, actions) uses significantly larger type
• Secondary or contextual information may be smaller, lower contrast, visually de-emphasized
• No critical flow relies on small text alone to convey meaning

Readability is preserved where it matters most.

Color & contrast: Accessibility supports clarity, it does not flatten hierarchy.

• Standards must not limit comprehension, speed, or focus
• Primary actions and key data must always be the most accessible elements on screen
• Extreme hierarchy is used to help users, not confuse them

Across all platforms, SODAX communication should:

• reinforce clarity over hype
• acknowledge real execution constraints
• position SODAX as complementary infrastructure
• prioritise understanding over persuasion

Format may change. Claims do not.

Primary role: Reach, visibility, and participation in the broader infrastructure conversation.

What success looks like: SODAX posts are shared because they articulate something others recognise as true.

Tone

• Conversational
• Lightly opinionated
• Self-aware

Strong points of view are encouraged, as long as they:

• describe reality,
• avoid superiority framing,
• and do not imply exclusivity or guarantees.

What works well

• Short observations about execution reality
• Educational threads explaining one idea clearly
• Commentary that connects multiple ecosystem pieces

Example patterns:

“Most cross-network failures aren’t about messaging. They’re about liquidity and timing.”

“Execution across networks is asynchronous by default. Designing as if it isn’t is where most UX breaks.”

What to avoid

• Competitive callouts
• Dismissive hot takes
• Performance claims without context
• Language that suggests SODAX replaces other infrastructure

SODAX should sound like a participant, not a referee.

Primary role:

Credibility, depth, and trust with technically literate audiences.

Tone

• Calm
• Direct
• Respectful

Reddit rewards:

• transparency,
• patience,
• and honest acknowledgment of tradeoffs.

Guidance

• Engage where discussions already exist
• Explain how and why things work
• Be explicit about limitations

Avoid:

• slogans
• brand-forward language
• defensiveness

The goal is not to “win” discussions, but to be recognised as thoughtful infrastructure builders.

Primary role

Education, trust-building, and long-form understanding. SODAX YouTube content may include:

• interviews
• event content
• technical updates
• guides and tutorials

Tutorials

Tutorial content should:

• align directly with support.sodax.com
• reflect real product behavior
• explain what happens and why

Tone:

• human
• clear
• measured

The objective is confidence, not excitement.

Production guidance

• Faces on camera are welcome
• Overproduction is not required
• Visuals should support explanation, not distract

If a concept can’t be explained calmly on video, it isn’t ready to be communicated yet.

Anything said on X, Reddit, or YouTube must also be defensible on:

• the website,
• in partner conversations,
• and in documentation.

Social reach does not justify narrative shortcuts.

SODAX appears in partner contexts as enabling infrastructure. The partner owns the user relationship. SODAX enables execution behind the scenes.

Default framing:

“SODAX enables …”

Partner announcements should focus on:

• what the integration enables,
• why that capability matters,
• and how it fits into a broader execution flow.

Language guidance

Good:

• “SODAX enables cross-network actions without requiring custom execution infrastructure.”
• “This integration uses SODAX to coordinate execution across networks.”

Avoid:

• claiming ownership of the user experience
• implying exclusivity unless contractually true
• positioning SODAX as the primary product brand

SODAX visual presence should:

• be neutral, enabling content and partners to take priority
• proudly show product interfaces that SODAX enables
• respect partner brand hierarchy
• remain consistent with core visual identity
• in multi-logo stacks, use relative sizing and visual weight to balance differing logo needs

Case studies should focus on:

• the execution challenge
• why coordination mattered
• how SODAX participated
• what outcome was enabled

They should avoid:

• vanity metrics
• one-off edge cases
• hero narratives

The emphasis is repeatability, not exception.

In SDK and technical contexts, SODAX representation should be:

• precise
• constraint-aware
• consistent with Section 3 (Verbal identity)

Clarity always beats persuasion.