Skip to content

Amounts

String Theory uses a highly flexible amount system to represent assets. It’s capable of representing any world currency, proprietary currencies (like loyalty points), and even non-fungible assets like real estate. It does this by storing three pieces of data with each amount: unit type, unit token, and unit count . We’ll dive into what each of these mean, with examples.

The unit type is a string that represents the category of asset, and often the maximum precision of that category. For example, String Theory supports six digit precision for world currencies out of the box using the unit type currency_micros . If the asset category doesn’t have fraction units then don’t worry about specifying it in the unit type. Something like loyalty_points would work just fine for non-fractional units.

Below we’ll provide some sample types, but remember you can create your own for whatever asset categories you have, there is no need to be limited to the ones explained here.

  • currency_micros : an ISO 4217 world currency with micro (6 digit) maximum precision
  • currency_centis : an ISO 4217 world currency with centi (2 digit) maximum precision
  • loyalty_points : a proprietary loyalty point currency with no fractional units
  • real_estate : an asset representing a real estate holding
  • nft : an asset representing an NFT in a blockchain

The unit token is a string that helps to determine the specific type of asset you are dealing with inside the category provided by the unit type. For example, if you are dealing with a world currency, the unit token would be the ISO 4217 currency code. The combination of the unit type and unit token should provide all the information you’ll need to be able to exchange that asset to another. We’ll get more into this later in the practical examples section.

  • ISO 4217 codes (e.g. USD, EUR, JPY)
  • referral_credit
  • loyalty_points
  • 373 Blue Spring St. East Meadow, NY 11554
  • property_8c56ef6b-bf92-4362-8815-322c44362334

The unit count is the numeric count of the asset that is represented by this amount. Unit counts are always whole numbers so it’s important to know the maximum precision you want to support for the unit type. This is because computers cannot accurately represent decimal numbers without losing precision. For example, if you are dealing with USD you’ll want to at least support hundredth’s precision as cents are commonly used when dealing with US dollars.

If you are using the String Theory UI you’ll see currencies, in particular, formatted as decimals in the international format appropriate for that currency for your convenience, but all APIs will always return only whole numbers for unit counts.

(In currency_micros USD)

  • 1000000 (1 USD)
  • 350000 (35 cents)
  • 25 (25/1,000,000 of a dollar)
  • 2.38
  • 150281.0000001

Some practical examples of amounts:

$3.53 USD
Unit type: currency_micros
Unit token: USD
Unit count: 3530000
€4.75 EUR
Unit type: currency_centis
Unit token: EUR
Unit count: 475
47,000 Frequent Flier Miles
Unit type: miles
Unit token: program_7183211234
Unit count: 47000
4,566.75 loyalty points
Unit type: loyalty_point_centis
Unit token: china_loyalty
Unit count: 456675
Real estate
Unit type: real_estate
Unit token: 7441 5th St. NY, NY 10153
Unit count: 1
350.75 referral credits
Unit type: referral_credit_micros
Unit token: USD
Unit count: 350750000
Chimp NFT
Unit type: ethereum_wallet
Unit token: 0xb794f5ea0ba39494ce839613fffba74279579268
Unit count: 1

String Theory’s amounts are designed to provide enough information to be able to exchange between two amounts (or tell if they are incompatible) without having to look at additional metadata. Here are some examples of how you would use amount data to exchange amounts.

$3.53 USD
Unit type: currency_micros
Unit token: USD
Unit count: 3530000
€3.22 EUR
Unit type: currency_micros
Unit token: EUR
Unit count: 3224500
  1. Check that unit types are exchangeable
  2. Look up conversion rate between unit tokens
  3. Find 0.91 USD → EUR
  4. Produce a new amount, with the target unit token and converted unit count
$3.53 USD
Unit type: currency_micros
Unit token: USD
Unit count: 3530000
$3.53 USD
Unit type: currency
Unit token: USD
Unit count: 3.53
  1. Check that unit types are exchangeable
  2. Find they can be converted, if the unit tokens match
  3. Ensure unit tokens match
  4. Find rate of 0.0000001
  5. Produce a new amount, with the target unit token and converted unit count

Note: this would be only for display, fractional amounts cannot be stored in the system.

Real estate
Unit type: real_estate
Unit token: holding_e1f29e8fd139963
Unit count: 1
$750,000 USD
Unit type: currency_micros
Unit token: USD
Unit count: 750000000000
  1. Check that unit types are exchangeable
  2. Find that they are, if there is a valid sale price
  3. Lookup sale price for holding_e1f29e8fd139963
  4. Produce a new amount, with the sale currency and sale price

String Theory has first class support for exchanging amounts and recording exchanges. This can be complex, particularly if you manage non-traditional assets, but we provide lots of tools and flexibility. See the exchanges documentation for detailed information.

You might have noticed some strangeness with how String Theory handles fractional numbers. We have a maximum precision as part of the unit type, and the unitCount is whole numbers only. Why is this?

The answer is a bit complex if you don’t understand how fractions are stored in a computer (binary fractions wikipedia), but the simple summary is this:

Computer systems are not capable of precisely storing fractional values, only approximations

It can get really close, but not exact when dealing with fractions. Unfortunately, these small approximations can add up to a big of discrepancy over millions of transactions. String Theory avoids this problem by having the precision declared in advance and then storing only whole numbers.

It sounds small, and adds weirdness to using the system, but we promise that if you store fractions in any monetary system this will eventually become a problem.