Introduction
Motion is often the least-tokenized part of a design system. Color, spacing, and typography are routinely tokenized and machine-readable. The 150 ms hover on a button, the overshoot on a bottom-sheet transition, the 600 ms fade on a modal: these often survive only in a designer’s memory, a prototype file, or a hand-tuned CSS transition line.
The DTCG Format Module 2025.10, published 28 October 2025 by the Design Tokens Community Group, changes that. It is the first stable version of the spec, which states that “This specification is considered stable.” It defines two primitive motion types, duration in Section 8.5 and cubicBezier in Section 8.6, and one composite type, transition in Section 9.5, which combines them.
In this post you’ll learn what those types are, what a valid token looks like, and a checkable rule set an AI agent can run against a token file. No tool demos and no benchmarks: just the spec, the rules, and what they mean for your system.
Why This Matters: Token Adoption Is Growing
The zeroheight Design Systems Report 2025 reports that design token adoption rose from 56% to 84% in its survey. When tokens are the shared source of truth between designers and engineers, every value you want to standardize has to live in the token file. If easing curves exist only in a designer’s head or in a one-off CSS rule, the token file is missing part of the system. That is the gap 2025.10 addresses. Because it is a community-group spec rather than a vendor feature, it does not tie you to a single tool.
The Motion Types in DTCG 2025.10
Duration (Section 8.5)
A duration token declares $type: "duration", and its $value is an object with two keys: a numeric value and a unit. The unit may only be "ms" or "s". No other unit strings are valid.
Cubic Bezier (Section 8.6)
A cubic bezier token declares $type: "cubicBezier", and its $value is an array of exactly four numbers: [P1x, P1y, P2x, P2y], the two control points of the curve. The y coordinates may be any real number, while the x coordinates are restricted to the range [0, 1] (Section 8.6). A y value above 1 produces overshoot.
Transition (Section 9.5)
A transition token declares $type: "transition". Its $value is an object with duration (a valid duration), delay (a valid duration), and timingFunction (a valid cubic Bézier curve). Section 9.5 notes that transition tokens do not specify which UI property is transitioned, so they describe timing only.
A Worked JSON Example
Here is a single token group containing both primitive motion types, with valid values:
{
"motion": {
"duration": {
"fast": {
"$type": "duration",
"$value": { "value": 150, "unit": "ms" }
},
"deliberate": {
"$type": "duration",
"$value": { "value": 0.6, "unit": "s" }
}
},
"easing": {
"standard": {
"$type": "cubicBezier",
"$value": [0.4, 0, 0.2, 1]
},
"overshoot": {
"$type": "cubicBezier",
"$value": [0.34, 1.56, 0.64, 1]
}
}
}
}Both allowed unit strings appear: "ms" and "s". In each bezier array, the first and third numbers (the x coordinates) fall within [0, 1]: 0.4 and 0.2 for standard, 0.34 and 0.64 for overshoot. The overshoot token’s y value of 1.56 exceeds 1, which is valid because only x is bounded.
How an AI Agent Can Verify Motion Tokens
The rules below are an explicit, checkable rule set an agent can run against any token file. Treat them as a verification plan you can implement in a script or an agent checklist. They are not a report of a test we ran.
- Structure check for durations. For every token where
$typeequals"duration": check that$valueis an object containing a numericvaluekey and aunitkey. - Unit check. For every duration token: check that
unitis exactly"ms"or"s". Any other string, including"us"or"frames", fails. - Shape check for beziers. For every token where
$typeequals"cubicBezier": check that$valueis an array of exactly four numbers. - Range check. For every cubicBezier token: check that the first and third elements (P1x and P2x) are within [0, 1] inclusive. The second and fourth elements are not range-checked.
- Reporting. Report each failure with the token’s path (for example,
motion.easing.overshoot), the rule violated, and the offending value.
These checks are deterministic and need no rendering. Each rule gives a yes-or-no answer for every token in the file, so an agent can run them over a whole file and report failures with exact paths.
Style Dictionary describes itself as “forward-compatible with the Design Tokens Community Group spec” (styledictionary.com). Tokens Studio (docs.tokens.studio) documents tokens that are reusable across border radius, spacer units, semantic color, and typography. An agent checking an export from either tool should expect a file shaped like the example above, but confirm the structure against the spec rather than trusting the tool.
Known Gaps
The 2025.10 spec defines timing: durations, cubic bezier curves, and transitions built from them. It does not define a spring type or a keyframe type in Section 8.x. A spring, with its mass, stiffness, and damping parameters, is not part of this version. This is a statement about what 2025.10 does not define, not a prediction about future versions.
Section 8.8 also lists font style, percentage, and file as types still to be documented, so the spec openly marks its own incomplete areas.
Teams that need springs or keyframes today must store them outside the standardized types, for example as custom metadata. That works, but it breaks machine-readability, which is the problem tokens exist to solve.
FAQ
Q: Can I use unit: "us" or "frames" for a duration?
No. The spec restricts duration units to "ms" or "s" (Section 8.5).
Q: Can a cubicBezier y value be greater than 1 or negative? Yes. The y coordinates may be any real number. Only the x coordinates are restricted to [0, 1] (Section 8.6).
Q: Does 2025.10 include spring or keyframe token types?
No. The motion types defined are duration, cubicBezier, and the composite transition (Section 9.5). Spring and keyframe types are not defined in this version.
Q: Which tools implement this? Style Dictionary describes itself as forward-compatible with the DTCG spec (styledictionary.com). Check each tool’s documentation for the specific types it supports.
The Bottom Line
DTCG 2025.10 makes motion timing machine-readable in a spec the community group calls stable. It defines two primitive types, duration and cubicBezier, plus the composite transition, and it has strict validation rules an agent can check deterministically. It covers timing only. Springs, keyframes, and richer motion semantics remain outside the spec. Where token adoption is already high (84% in the zeroheight 2025 survey), adding these types to the token file is the next step.
How This Guide Was Built
This guide is based on the official DTCG Format Module 2025.10 specification and public reports: the zeroheight Design Systems Report 2025, and the Style Dictionary and Tokens Studio documentation. The team did not run these tokens in a live design tool. All examples and verification rules are derived from the spec text, not from hands-on tool testing.