JUSTYPE
Profile
Learn JUSTYPECURRENT PRODUCT EXPLAINED

Markets are complicated. Describing one shouldn’t be.

You describe what a token should do. JUSTYPE turns the supported parts of that instruction into structured rules, checks what it can, and shows the result as a Behavior Score.

01

JUSTYPE is a rule-design product

It makes a complex market configuration easier to describe and easier to inspect.

Most token tools begin with parameter fields. JUSTYPE begins with the behavior: take a fee on sells, route part of it to buybacks, lower it later, or limit one trade. The current product recognizes supported phrases and turns them into a typed frontend configuration.

That configuration is useful because it forces an ambiguous idea into explicit values and relationships. Classic V1 can separately create a standard UERC20 and hookless ETH market through canonical Uniswap infrastructure, but production broadcasting remains feature-gated.

02

The sentence changes representation

One instruction, changing representation without becoming code.
  1. 01INSTRUCTION

    The exact sentences you write

  2. 02PARSE

    Supported phrases become typed candidates

  3. 03NORMALIZE

    IDs, shares and limited defaults settle

  4. 04VALIDATE

    Implemented errors and warnings run

  5. 05CANONICAL RULES

    The saved TokenRule[] specification

  6. 06BEHAVIOR SCORE

    The same active rules become visual

The parser does not execute prose. It recognizes supported patterns, preserves anything it does not recognize, then normalization and validation create a reviewable rule set. If a sentence is unsupported, JUSTYPE asks you to fix it instead of making something up.

03

A small language, not arbitrary code

Six human families over twenty-one structured rule types.
FEEbuyFee · sellFee
SPLITrelationship, not a rule type
DESTINATIONbuyback · burn · rewards · liquidity
TIMEfee change · activation · trading open
LIMITtrade · wallet · access · protection
MILESTONEbuyerRewards

A primitive is a human family such as FEE, TIME, or LIMIT. A rule is the typed object that carries actual values. SPLIT is a relationship among a fee and its destination rules; it is not an internal opcode.

The implementation supports 21 structured rule types and 28 manual catalog choices. Support here means the frontend can represent and display the behavior. It does not mean a JUSTYPE contract enforces it.

Read the primitive map or inspect every rule type.

04

One instruction can become a composed specification

Routing · 01

Split one collected fee

Human instruction
Take 2% on sells. Use half of sell fees to buy back MOG. Send the rest to stakers.
Normalized rules
sellFeeTake 2% when someone sells.
buybackUse half of the sell fee to buy MOG.
stakingRewardsSend half of the sell fee to stakers.
Validation
Recognized YESComplete YESErrors 0Warnings 0
Behavior ScoreSELL 2% → 1% BUY MOG + 1% STAKERS
SELL2%
1%BUY MOG
1%STAKERS

Frontend configuration example. No onchain output or transaction is implied.

05

Behavior Score explains the configuration

Configured rulesBehavior Score is a view, not another source of facts.
SELL4%
2%BUY MOG→ BURN
1%STAKERS
SELL4%NOW
THEN1%DAY 7
MAX SELL0.5%OF SUPPLY
001025050075
1001K MOG
FEE source + percentageROUTE effective allocationsTIME scheduled changeLIMIT configured boundaryMILESTONE reward interval

The score is generated from the active normalized rule objects. It shows what the saved configuration says: source, percentage, destination, timing, limits, and milestones. It is not a safety rating, audit, market forecast, or execution proof.

06

Current product and planned execution stay separate

One product, with execution states kept explicit.
IMPLEMENTED IN CODE
  1. 01Parse
  2. 02Normalize
  3. 03Validate
  4. 04Review + Behavior Score
  5. 05Wallet + canonical market reads
  6. 06FEATURE-GATED CLASSIC V4
PLANNED · NOT DEPLOYED
  1. ARule compiler / adapter
  2. BHook execution
  3. CStock-token pair execution

Classic launches use canonical Uniswap contracts. No JUSTYPE hook or programmable execution contract is deployed.

Current pipelineClassic + programmable boundary

The implemented Classic path uses a canonical LiquidityLauncher transaction to create a fixed-supply UERC20 and hookless TOKEN / ETH pool. Real PoolManager Swap events drive address-page charts and trades. The production launch flag remains off. Optional v4 hooks are relevant to the future rule engine, but no JUSTYPE Hook Engine exists or is deployed.

07

What JUSTYPE does not do today

01It does not generate or execute Solidity from your sentence.

02It does not enforce the 21 JUSTYPE rule types in a Classic pool.

03It does not enable production launch merely because a wallet connected; preflight, the safety flag, an explicit action, and wallet approval remain required.

04It does not verify that a configuration or market is economically safe.

05It does not publish internal fixture markets or activity as real chain data.

06It does not execute USDG or tokenized-stock pairs.

08

Inspect a programmable token before you interact

  1. Read every active rule.

    Do not rely on a compact headline. Follow each fee source, branch, time change, limit, and milestone.

  2. Separate clarity from quality.

    A clear Behavior Score can describe a bad incentive. Validity is not endorsement.

  3. Confirm execution evidence.

    For an address route, verify Robinhood Chain, token, PoolId, launch transaction, strategy, pair, hook status, and whether the rule profile says enforced. Classic V1 must say false.

  4. Understand dependencies.

    Wallets, RPCs, routers, pools, custody contracts, APIs, time, price, access, and future oracles can introduce failure modes.

  5. Assume value can go to zero.

    A real market and readable mechanics do not create demand, durable liquidity, honest creators, or investment safety.