The simplest triangular-number patterns are related to repdigits generated from the 3, 6, and 9 series. The side-by-side table above shows the corresponding triangular numbers, and the pattern for repdigits of 3 can be written as the following theorem:

Theorem1.Foranyrepdigit [ 3 ] m withmnumberofdigitsinit, thecorrespondingtriangularnumbercanbewrittenas [ 5 ] m − 1 [ 6 ] 1 [ 1 ] m − 1 .

Similarly, the same side-by-side table suggests the following statements for repdigits of 6 and 9:

Theorem2.Foranyrepdigit [ 6 ] m withmnumberofdigitsinit, thecorrespondingtriangularnumbercanbewrittenas [ 2 ] m [ 1 ] m .

Theorem3.Foranyrepdigit [ 9 ] m withmnumberofdigitsinit, thecorrespondingtriangularnumbercanbewrittenas [ 4 ] 1 [ 9 ] m − 1 [ 5 ] 1 [ 0 ] m − 1 .

The triangular number of repdigits based on 1, 2, 4, 5, 7 and 8 does not follow the simpler form as shown in the previous subsection. We now try to find the patterns and constants in this sequence using the tables attached below. A colour-coded view to identify the constants and patterns for each repdigit, as presented in Figure 2 used as a primary sample in this research paper, along with Supplementary Figures S1-S5. Let’s understand the constants and patterns with Figure 2. It consists of vertical patterns of constants, the differences between successive constants, and digits inherited from one constant to the next. Vertical patterns have left and right patterns used to assemble the triangular number of a repdigit.

The colour-coded view in Figure 2 shows that a hidden three-digit constant vertical pattern follows in the middle of triangular numbers as it ascends. The pattern again repeats itself after every 9 triangular numbers. The symmetrical pattern starts from the second triangular number 66 and can be written in form of a set as,

The common feature of these vertical constants is that consecutive terms alternate between differences of 555 and 556, as shown in Figure 2. With further research, this regularity may enable the next constant to be computed directly, rather than determined manually. A further observed feature is that certain digits are inherited from the m th triangular number when constructing the ( m + 1 ) th triangular number. These inherited digits form a closed loop, analogous to the constant patterns discussed above, and may provide insight toward logarithmic derivations (or compact generation rules) for values of V const . Further details are provided in Section B.

Figure 1. Simplified introductory view of the Triangular Number Matrix system for repdigit 1. The figure highlights the synchronization between vertical patterns, pattern index, and horizontal patterns. The dark green rows show cycle alignment: every ninth increase in the pattern index completes a full vertical-pattern cycle, while the horizontal-pattern composition expands by one additional repeated block on each side.

Figure 2. Triangular number series of repdigits of 1.

Apart from this three-digit vertical pattern, there is also a noticeable horizontal pattern followed by the triangular number series.

Left Horizontal Pattern—this represents the patterns or parts of patterns that repeat horizontally on the left side of the vertical constant.

Right Horizontal Pattern—this represents the patterns or parts of patterns that repeat horizontally on the right side of the vertical constant.

So far, we have clearly identified all the vertical and horizontal constants and symmetries present in them. Now, we have all the ingredients for writing a triangular number of any n th repdigit [ 1 ] n .

In previous sections, we discussed the ability to write the triangular number of a repdigit using constants and patterns. This raises a natural question: can the same idea be used for non-repetitive digits? The answer is yes. One approach is to use a shortcut anchor, or multiple shortcut anchors, based on a nearby repdigit in order to reduce the direct computation required.

For a lower anchor x and an offset y ≥ 0 , we use the identity

where

Using this identity, a known triangular number can serve as an anchor for computing a nearby value. If x is chosen as a convenient anchor (for example, the nearest repdigit), then the triangular number of x + y can be obtained by combining the anchor value Trag ( x ) , the linear term x y , and the smaller triangular correction Trag ( y ) . When y is small, the cost of the remaining direct computation is correspondingly reduced.

For example, if our anchor triangular number for n = 66 is 2211. What if we want to calculate the value for n = 70 using this novel approach? It would require the following steps: 70 − 66 = 4, hence, 2211 + (66 × 4 + Trag(4)) = 2211 + (264 + 10) = 2485.

In the running example, the remainder is 4. In general, if the remainder is multi-digit, we iterate the same reduction procedure until a single-digit remainder is obtained. Table 2 illustrates a case that reduces to a single-digit remainder immediately, while Table 3 shows a case that requires iteration.

Table 2. Example A: the remainder reduces to a single digit after one sub-anchor step.

Table 3. Example B: the remainder is multi-digit, so the same procedure is iterated until a single-digit remainder is reached.

This step completes the procedure for computing triangular numbers of non-repeating digit sequences using shortcut anchor(s). The approach is amenable to parallelization: for example, in Example B ( n = 4101 ), one can first enumerate the multi-digit remainders generated during the anchor reduction, compute the corresponding triangular components independently, and then aggregate the partial results as in Steps 1 - 2 of Example B. A quantitative evaluation of the runtime benefits of this parallel strategy is left for future work.

So far in the paper, we have learnt to effectively write the triangular number of any repetitive digit using constants and patterns. However, repdigits are not the end of the story but a step towards a new way of calculating triangular numbers. The real challenge would be to write the triangular number of any random non-repetitive digit. For the answer to this evident question, we have tried to give using our changeofbasetheory in Table 4.

The premise of the idea is that every repdigit’s triangular number in other base systems represents a different but also triangular number in the base 10 system. For example, in the base-7 system, where the highest number is 6, we can easily observe these phenomena. Here are the triangular numbers in base 7 and their corresponding base-10 conversions for the number 6. Let’s look at Table 4. Every repdigit of 6 in base-7 represents a non-rep triangular number in base-10. These non-repdigits in base-10, can easily be generated with a logarithm as,

Table 4. Triangular number series of repdigit number of 6 in base-7 with corresponding non-repdigits of them in base-10.

48 next number is 342 since: 48 + 6 * 7 * 7 = 342 342 next number is 2400 since: 342 + 6 * 7 * 7 * 7 = 2400 2400 next number is 16,806 since: 2400 + 6 * 7 * 7 * 7 * 7 = 16,806

Now let’s look at the triangular numbers of these non-repdigits. The triangular number of 48 in the base 10 system corresponds to 3300 in the base 7 system. We must convert the base 7 value (3300) into base 10, yielding 1176. This pattern persists; to determine the triangle number for 342, we convert the base 7 value of 333000 to base 10, yielding a triangular number of 58,653 for 342. The same applies to 2400, as evidenced by Table 4.

The base 36 system produces distinct triangular numbers using patterns that do not exist in any other base system, since the base 36 method generates different numerical sets than those produced by base 7 or base 6. In all numeral systems, we can produce unique numbers that transform into base 10 non-repeating (or repeating) digit triangular numbers. This underscores a significant point that non-repdigit values can serve as anchor points in the same manner as repdigit values in the base-10 system. For instance, the digits 48, 342, 2400, 16,806, 117,648, and 823,542 correspond to the triangular numbers 1176, 58653, 2,881,200, 141,229,221, 6,920,584,776, and 339,111,124,653, respectively. These triangular numbers, akin to repeated digits demonstrated earlier with the calculator, allow for the application of analogous reasoning.

To compute the triangle number for 49, we can utilise the known triangular number for 48, which is 1176. We only need to calculate 1176 + 49 = 1225 and continue accordingly. This practice expands a calculator to function not just with repdigits but also to utilise non-repdigit triangular numbers as anchors to streamline the system. Using this approach, we can speed up the calculations process since now we have more anchors than just repdigits and can more granularity access the TriangularMatrixSystem with more shortcuts.

This could be done by parallelization of the conversion process by breaking the big n-th base digit into smaller chunks, paralleling the big digit conversion, and finally adding up the sum. For example, let’s take the anchor number from the table of base 6 number 333000 and break it into three chunks of 33, 00, 00, and convert these as a separate parallel task. In the base 10 system, this can be represented as:

For Chunk 1 (33 base 6):

For Chunk 2 (30 base 6):

For Chunk 3 (00 base 6):

And the final formula is:

Multi-BaseAnchors The following example demonstrates how a multi-base framework can be used to locate the closest anchor point for a non-repdigit number. Figure 6 visualizes this comparison.

Figure 6. Multi-base anchors for locating the closest repdigit anchor point to a target non-repdigit number in base 10. The target value 5760 is highlighted in red, the closest anchor is highlighted in green, and the corresponding base-10 anchors are highlighted in blue.

Figure 6 illustrates the process of locating the closest anchor point for the target number 5760. In base 10, this number lies between the anchor points 5555 and 6666. However, by extending the search to repdigit anchors from nearby bases—such as base-9: 8888, base-9: 7777, base-11: 4444, and base-12: 3333—it is possible to identify anchors that are even closer when converted into base 10.

This makes it possible to refine the search for the nearest anchor point to 5760 by comparing the corresponding base-10 values obtained from repdigits in different bases. In Figure 6, the closest anchor point is 5740, which gives a distance of −20 (5740 − 5760 = −20). This is the smallest absolute distance shown in the table, and it is obtained from the base-9 repdigit anchor after conversion into base 10.

Table 5. Base-4 patterns as base-10 triangular anchors.

Table 5 illustrates how a repdigit triangular-number pattern in base 4 can convert into base-10 non-repdigit anchors and their corresponding triangular numbers. To test the reliability of this process, bases 3 through 36 were examined to determine whether, for each ascending repdigit, the corresponding triangular number—after conversion to base 10—would remain a triangular number in base 10. For each base, the first 100 ascending repdigits were tested for every valid digit (for example, in base 2, digits 1 and 2 were each tested across their first 100 repdigits). The results showed that the corresponding triangular number of every tested repdigit remained triangular in base 10, supporting the reliability of the process illustrated in Figure 6.

Note: A remaining challenge is to make conversion between base systems significantly faster and to implement a software module that improves conversion speed. At present, this paper does not claim high-speed computation for non-repdigit numbers; the demonstrated speed improvements apply to repdigits only, which is sufficient for the cryptographic use case developed in this work.

Sections 2 - 5 establish the TriangularNumberMatrix as a constructive system for generating large triangular numbers from digit-level regularities, rather than by direct evaluation of the conventional formula T n = n ( n + 1 ) / 2 . The central observation is that, for structured index families—most notably repdigits—the corresponding triangular numbers exhibit stable internal regularities that persist as digit-length grows. This enables an assembly-first view of computation: once the relevant constants and scaling rules are identified for a family, increasing the requested length does not require increasingly expensive large-integer multiplication and division, but rather the repeated application of the same pattern rules.

This view yields a protocol-relevant abstraction. Instead of treating each T n purely as a scalar, Sections 2 - 5 implicitly define a collection of deterministic digitobjects indexed by compact parameters. Concretely, fixing a base b and a repdigit family (or more generally, a pattern identifier), each admissible length ℓ determines a specific base- b digit string representing a triangular number instance generated by the matrix rules. In Section 7, this abstraction is formalized as catalogsacrossbases; Section 6 clarifies why the mathematical construction naturally admits such a catalog interpretation and why that interpretation is relevant under modern cybersecurity threats.

A key ingredient for any catalog-style construction is that members can be generated reproducibly from short descriptors. In this work, Theorems 1 - 4 provide precisely the family-level determinism needed for that role.

Theorems1 - 3(closed-formrepdigitfamilies). These theorems give explicit digit-structure formulas for repdigits based on 3, 6, and 9, each parameterized by the repdigit length m . The resulting forms specify how the triangular number representation grows with m and therefore define a direct mapping from a short descriptor (family, length) to a unique digit expansion.Theorem4(generalrepdigitassemblyviascalablereduction). Theorem 4 generalizes the construction to repdigits whose triangular numbers are assembled from: 1) horizontal constants ( L const , R const ) that repeat around 2) a vertical constant selected by a scale-dependent key. In the notation used throughout the paper, the theorem can be summarized as a structured concatenation:

where P ℓ is the horizontal pattern length, N L / R = m − 2 , r = N L / R mod P ℓ , and q = ( N L / R − r ) / P ℓ . Here ∥ denotes concatenation, and the bracketed repetition notation follows the conventions already established in Sections 2 - 3.

Together, Theorems 1 - 4 supply the mathematical backbone for catalog construction: they define families of digit objects whose members are determined by compact parameters (family identifier and length) and are generated by rule-driven assembly. This catalog viewpoint does not introduce new mathematics; it is a re-expression of the main results in Sections 2 - 3 in a form that is directly consumable by cryptographic protocol design (formalized later in Section 7).

A second requirement for protocol use is that large objects be addressable without transmitting or computing the full expansion. The scalable reduction method (Section 3) provides this property in two complementary ways.

Compactaddressing.

The scalable reduction method computes a scale-dependent key (e.g., via a digital-root style reduction) using only a small set of parameters such as the repdigit value and the repdigit length. This key is then used to select the appropriate vertical constant from V const . Because the key computation depends on a compact description rather than on enumerating all digits, the selection step remains feasible even when the repdigit length is extremely large.

Reproducibleexpansionbyassembly.

Once the vertical constant is selected, the remainder of the expansion is determined by repeating the horizontal constants and applying the appropriate cutoffs according to q and r (cf. Equation (11)). The expansion procedure is therefore deterministic and repeatable: the same descriptor yields the same digit object, and the generation process avoids full big-integer multiplication and division in favor of pattern concatenation.

This compact-address plus deterministic-expansion structure is the mathematical precursor to the short-form representations and catalog commitments introduced in Section 7. The present section does not formalize those protocol mechanisms; rather, it motivates why they arise naturally from the constructive content of Sections 2 - 5.

Section 5 extends the matrix framework beyond base-10 repdigits by leveraging the change-of-base perspective. Two points are central for the cryptographic motivation:

1)Multi-basegenerationincreasesthepoolofstructuredinstances.

Repdigits in other bases yield triangular-number representations that, when converted to base 10, correspond to distinct triangular numbers associated with non-repdigit values (Section 5). This produces a larger library of structured triangular-number instances, which can serve as additional reference points and can be generated efficiently as base-dependent patterns (e.g., the base-7 series for the digit 6 and its corresponding conversions).

2)Multi-baseprocessingsupportsparallelizableworkflows.

Section 5 demonstrates that base conversion itself can be parallelized by chunking a large base- b number into smaller blocks, converting each block independently, and combining the results via powers of b . This property aligns with the general computational objective of decomposing large-digit operations into schedulable parallel tasks.

3)Multi-baserepresentationsexpandtheparameterspaceanattackermustconsider.

In the later protocol framing, operations can be expressed over multiple bases and multiple catalog families. Even when catalogs are public, multi-base diversity increases the number of plausible representations and families that may underlie an observed computation. Informally, a larger set of bases increases the combinatorial surface of admissible constructions (base choice × family choice × length choice), which expands the space of hypotheses an adversary must consider when attempting to reverse-engineer or exhaustively search over protocol-relevant parameters. Figure 6 illustrates this concretely in the computational setting by showing that closer anchor points can be obtained by checking repdigits in nearby bases and converting back to base 10; the same multi-base diversity also underpins the protocol design surface considered in Section 7.

The preceding sections establish a mathematical engine for producing large, structured, base-dependent triangular digit objects from compact descriptors. This motivates a natural question: whyshouldsuchdigitobjectsbeconsideredincryptographicdesignatall? Beyond purely computational interest, the motivation is driven by practical authentication risks: large-scale credential theft and password database breaches enable offline guessing attacks that can lead to unauthorized access even when online rate limiting is effective. Section 7 therefore provides the security context for using structured, sliceable digit objects as a protocol substrate and motivates the rolling-state, layered authentication construction formalized in the same section, which is designed to mitigate the use of stolen credentials and reduce unauthorized access. In addition, Section 6 situates this direction within the broader long-horizon threat landscape, including the prospect of cryptographically relevant quantum computing and the corresponding pressure toward post-quantum security assumptions.

As advances in highly parallel hardware continue to reduce the cost of large-scale computation, cryptographic designs that rely solely on “doing the math faster” face growing pressure—both from commodity GPU acceleration and from longer-term quantum risk to widely deployed public-key primitives. A cryptographically relevant quantum computer would, in principle, undermine RSA and elliptic-curve systems via quantum algorithms, and this prospect has already motivated standardization and migration efforts in post-quantum cryptography (PQC), including NIST’s finalized PQC standards (e.g., ML-KEM for key establishment) and vendor deployments that begin protecting data in transit against “harvest now, decrypt later” (HNDL) threats. In this context, the present work frames an alternative computational emphasis as assemblyversuscompute: instead of depending primarily on a small set of algebraic problems aligned with massive parallel arithmetic, the construction explored here emphasizes structured composition—using Triangular Number Matrix patterns and base-dependent representations—so that recovering the message resembles reconstructing a constrained jigsaw (a combinatorial assembly problem) rather than optimizing a single dominant mathematical operation.

Taken together, Theorems 1 - 4 provide deterministic pattern families that can be instantiated at scale from compact descriptors, while the multi-base processes in Section 5 enlarge the universe of available structured instances beyond base-10 repdigits. Section 7 formalizes how these families are treated as public catalogs across bases and how compact descriptors enable efficient access to structured digit material within those catalogs. The aim is not to replace standardized post-quantum public-key primitives, but to articulate a complementary design surface in which the dominant operation is structured composition over many base-dependent catalog instances—consistent with the “assembly versus compute” framing introduced above—and to present a proof-of-concept authentication construction (TLV) that leverages this structure under modern breach and offline-attack considerations.

Every last digit’s triangular number in any base has a simple pattern that is easily reducible or can be represented in a short form as (base = 4, number = 3, length = 5). For example, (base = 4, number = 3, length = 5) would be equal to reducing 133333200000 for the expansion of number 3, that is written in base 4, and is the 5th triangular number represented as 8,386,560 in base 10, see chart below 4. That’s why we can represent it as (base = 4, length = 5) which could be easily assembled back into its original form of 133333200000 based on the calculator rules presented earlier.

This pattern is not limited to just base 4, but extends to every base. For example, in Base 3, the number 2 being the highest digit, number 22’s triangular number is 1100; however, we will display an expanded pattern at 20th length, like 111111111111111111111111 000000000000000000000000 to highlight correlations as the pattern grows in length. Similarly, we can write a pattern for different base systems as in Table 6.

Table 6. Expanded triangular-number patterns for the highest digit in each base.

TLV proposes a rolling state interactive authentication mechanism to protect against dumping passwords during a data breach when an attacker takes all the data necessary to do an offline brute force attack to crack passwords in the database. The idea is to periodically change user passwords automatically and seamlessly within a defined date threshold (ie, user password/token is older than 2 days). The authentication system precomputes, in memory, the per-layer op templates and their bounded arg-tags from public parameters and the committed catalogs; after the client sends the session-nonce, the server transiently returns this bundle to start state assembly. These arg-tags/ops are never persisted server-side and are discarded after the attempt; each new session-nonce yields fresh ops and arg-tags. We consider a set of committed catalogs across bases: each catalog (b, n) maps legal lengths. Below, we define the key terminology in TLV mechanisms.

1) Per-layeroptemplates: server-precomputed operation descriptors for each layer (schema: b , n , l , L pos , R pos , D len ) derived from public parameters and the committed catalogs, defining exactly which digit slices are read and mixed.

2) Boundedarg-tags: server-computed index sets selecting a bounded subset of those op templates per layer; “bounded” ensures indices are in-range for the corresponding templates (no out-of-bounds positions); conveyed transiently and never persisted server-side.

3) Session-nonce: a server-generated, high-entropy per-session nonce that the client echoes back to initiate binding and state assembly for the attempt; each new session-nonce triggers fresh op templates and arg-tags that are passed to the user once.

This builds “private user rules” and periodically syncs with legitimate users to refresh the password/token if the defined date threshold is exceeded. A legitimate user passes the “private user rules” to the server in order to undergo a layered interactive authentication process and gain access to the protected systems. The next section discusses the strategy used for TLV cryptography.

To make the TLV architecture precise, we distinguish between operationtemplates, layers, and channels. This clarification separates the core interactive authentication construction from higher-level configurable protocol profiles.

Operationtemplates.

An operation template is a bounded catalog-derived descriptor of the form

where ( b , n , ℓ ) identifies a legal catalog member and ( L pos , R pos , D len ) determines the left and right windows used in the local rip-and-mix computation. In TLV, these operation templates are precomputed by the server from public parameters and the committed catalogs, and are paired with bounded arg-tags that identify which templates are active for a given attempt.

Layer.

A layer is a bounded ordered collection of operation templates together with its associated arg-tags and folding rule. Intuitively, a layer represents one verification unit in which only the operations selected by the transmitted arg-tags are evaluated, while the remaining templates in that layer are ignored for that attempt. The outputs of the selected operations are then combined to form a single layer commitment or layer digest. Thus, a layer is not a single operation, but a bounded sequence of eligible operations from which only a transiently selected subset is activated in a given session.

Channel.

A channel is a use-case-specific verification profile composed of one or more layers, together with the rule by which their outputs are combined and accepted. In this paper, the primary fully described channel is the authenticationchannel. Other channels are best viewed as configurable extensions built on the same TLV structure rather than as separate cryptographic systems.

Authenticationchannel.

In the authentication setting, the server first precomputes the per-layer operation templates and bounded arg-tags from the committed catalogs and public parameters, then transiently returns these values after receiving the session nonce. The client uses the received private user rules to assemble the required per-layer responses and returns the resulting verification material. The verifier evaluates only the selected operations in each layer, forms the corresponding layer digests, and then folds these layer outputs into the final commitment checked against the stored authentication state. In this sense, the authentication channel is a layered verification profile in which each layer contributes a bounded and selectively activated portion of the overall proof.

Whylayeringisuseful.

This structure serves two purposes. First, it keeps honest verification efficient because only a bounded subset of operations is processed per layer. Second, it increases attacker uncertainty in the offline setting because an adversary must reconstruct not only the underlying catalog-derived operations, but also the correct per-layer selection pattern across multiple layers, while learning only the final verification outcome and not any per-layer oracle. Accordingly, the role of layering in TLV is not merely organizational; it is part of the mechanism by which selective verification, rolling state, and bounded catalog access are combined into one authentication workflow.

Scope.

For the purposes of this paper, the term channel should therefore be read narrowly: it denotes an application-specific arrangement of TLV layers. The authentication channel is the main proof-of-concept construction developed here. Other possible channels, such as authorization, document access, or distributed transaction verification, are more appropriately presented as configurable TLV channel profiles based on the same layer abstraction (see Section B.3).

To make this architecture more tangible, Figure 7 illustrates the conceptual composition of TLV layers and shows how selected operations contribute to the final commitment used by the verifier. Each layer contains a bounded set of operation templates together with arg-tags that select which operations are evaluated in a given session. The selected operations produce per-layer digests ( H 1 , H 2 , ⋯ ), and the sequence of layer digests is folded to produce a final commitment H final that is compared with the stored verifier state during authentication.

Figure 7. Illustrative TLV layer composition. Each layer contains a bounded set of operation templates of the form ( b , n , ℓ , L pos , R pos , D len ) together with arg-tags that select which operations are evaluated in a given session. The selected operations produce a layer digest ( H 1 , H 2 , ⋯ ), and the sequence of layer digests is folded to produce a final commitment H final that is compared with the stored verifier state during authentication.

7.4.1. Catalog and op Model

Catalog. For each base b and pattern id n , the catalog defines a digitlanguage that yields, for any legal ℓ ∈ S b , n , a base- b digit string

Implementations expose random access to slices of D (by index and length) without materializing all N digits.

Optuple. Each operation is

with the following constraints:

b base; n pattern id; ℓ ∈ S b , n selects the specific member; together ( b , n , ℓ ) determine D and N . Leftwindow start L pos is 0-based from the left; Rightwindow offset R pos is 0-based from the right. Windowlength D len ≥ 1 . Bounds:

where c is the center.

7.4.2. Window Extraction (No Full Expansion)

Given D and N , define the two windows purely by indices:

Leftwindow:

Rightwindow:

Both slices are obtained by the catalog’s sliceAPI; the rest of D is never expanded.

Catalog’ssliceAPI = a local function/method that returns digits D [ a : b ] withoutexpandingallof D (e.g., generator or table lookup). No external calls.

7.4.3. Converting Only the Windows

We avoid hashing a billion digits by converting only the tiny slices to decimal. Two equivalent choices (pick one for the spec):

Localbase-bvalue(simpleandfast):

Encode each as a fixed-width decimal string (zero-padded to ⌈ D len log 10 b ⌉ digits).

Position-awaresnippet(stilltiny, bindstoposition)

Choose a small modulus 10 t (e.g., t = 2 ⋅ D len ). Let the global position of the j -th digit be P j (0 = most significant). Compute

using fast modular powers. Emit the last t decimal digits of each.

(Thiscaptures “consideringtheirposition” withoutheavybig-intwork.)

Rip-and-Mix Token

Normalize the two decimal snippets to equal width and interleave them (zip one digit from left, one from right). Optionally permute the interleave with a per-layer salt S i to prevent reuse:

Define the op’s rip-and-mixtoken:

where H is a 256-bit hash (e.g., SHA-256/SHA3-256) and S i is a per-layer salt such as

per-layer index sets supplied by the client that tell the verifier which few operations to evaluate (via a RAM-bound tag) before forming the layer digest. The goal is to keep honest logins fast while forcing offline attackers to search a larger hidden space (witness and indices) with no per-layer oracle. Tag’s scratch is deterministically derived from S i .

Example (tiny numbers for illustration)

Let the catalog define D 6 , 3 , 5 as the 12-digit base-6 string:

33333 000000

op = ( b = 6 , n = 3 , ℓ = 5 , L pos = 4 , R pos = 3 , D len = 3 ) Ldigits = D [ 4 : 7 ] = 3 , 0 , 0 → local decimal

Rdigits = D [ 12 − 3 − 3 : 12 − 3 ] = D [ 6 : 9 ] = 0 , 0 , 0 →

Interleave: “108” ⊥ “000” → “100800”. Token:

You compute such tokens only for indices in arg_tags; the rest of the layer is unaffected.

Nofullexpansion. All work is on O ( D len ) digits per selected op; typical D_len is tiny (e.g., 3 - 16). Hash cost is fixed and small.Client-heldindicesaddsearchspace. Offline attackers must guess ( b , n , ℓ , L pos , R pos , D len ) and the per-layer arg_tags_i across K layers, with noper-layeroracle—only the final commitment decides.Saltspreventprecomputation. Including S i in t ( ⋅ ) and T i kills table-reuse across sessions/epochs.Catalogrotation. If catalogs change over epochs, you can bind a version V into S i or the fold; old offline transcripts won’t verify under a new V .Boundsenforcement. Reject ops whose windows fall out of range; do so in constant time and without per-layer leakage (fixed-length transcripts, padded timing).

Serverbreach(butnottheclient’ssecrets). The attacker sees only C E (only final epoch commitment) and system parameters. To test a guess, they must run the same selective RAM-walks for the (unknown) per-layer indices and still only learn success/failure at the final check.Catalogleakage. Harmless: catalogs are public by design. Strength comes from the client-held indices and salted RAM-walks, and mathematical operations, not catalog secrecy.

Scope. By “polygonal” we refer to the standard figurate families:

Triangular: T n = n ( n + 1 ) 2 .Square: S n = n 2 .Pentagonal/Hexagonal(generalk-gonal): P k ( n ) = 2 ( k − 2 ) n 2 − ( k − 4 ) n .

We compare these families specifically for our catalog + rip-and-mixwindowsmodel, where an operation is ( b , n , ℓ , L pos , R pos , D len ) and we only ever extract tiny slices of the base- b digit string D b , n , ℓ rather than expanding the full number.

1) Catalog Density & Short Forms Across Bases

Triangular: Empirically yields the richest, dense “digit languages” across many bases (e.g., families of repeaters/structured blocks) that map to valid triangular indices for long stretches of ℓ . This yields large legal sets S b , n and many usable short descriptors per base. Multiple bases can be used to further increase richness. Square: Productive in a few bases (e.g., patterns that mirror squaring rules), but sparser than triangles; legal length sets S b , n tend to be thinner for compact patterns. Pentagonal/hexagonal/generalk-gonal: Catalogs exist, but short-form patterns are rarer, more brittle, and less reusable across bases.

Whyitmatters: Denser catalogs ⇒ more valid operations per layer without decimal work, more options for the client, and a larger hidden search space for the attacker.

2) Sliceability & Local Evaluators (Fast Windows)

Triangular: Many patterns allow fetching slices D [ a : b ] with minimal evaluators (no full expansion). L/R window extraction is cheap and uniform across bases.Square: Local evaluation is heavier due to carry interactions from squaring; feasible but less uniform. Higherk-gonal: Often needs more per-digit logic or partial expansions to locate digits, slowing window extraction.

Whyitmatters: A rip-and-mix token touches only O ( D len ) digits; triangular patterns keep this path simple and predictable.

3) Security Fit to Rip-and-Mix

All families share the same core security principle: hardness derives from client-held choices (witness, arg_tags, windows L pos , R pos , D len ) and final-only commitment. Trianglesprovideanedge: their dense catalogs offer more valid operations (larger m i ) and more cross-base variants, expanding the attacker’s offline search space for the same per-guess cost.

4) Operational Cost & Caching

Triangular: Best cache reuse (catalog-wide, salt-agnostic) for window locators and tiny digit evaluators; highly predictable performance. Square/others: More custom evaluators; higher risk of fallback to heavy arithmetic during window extraction. Performanceknob: Per-guess RAM and slice counts can be tuned. Total cost is via modular exponentiation—CPU-friendly, highly parallel, and not RAM-bound unless configured to be.

Here, we present the constants and patterns in repdigits of 2, 4, 5, 7, and 8, along with the mapping from digital roots to vertical constants, in the following Supplementary Figures S1-S6.

Figure S1. Triangular series of repdigit (2).

Figure S2. Triangular series of repdigit (7).

Figure S3. Triangular series of repdigit (5).

Figure S4. Triangular series of repdigit (8).

Figure S5. Triangular series of repdigit (4).

Figure S6. Mapping from digital roots to the corresponding vertical constants for repdigit (2).

B.1. Parallelization Enhancements

Both the multi-base method and the GPU-porting approach rely on dividing work into independent tasks that can be executed simultaneously. Instead of generating each triangular number via the direct formula T n = n ( n + 1 ) / 2 , we precompute anchors across bases and assemble numbers in parallel. Key strategies include:

1) Base-levelparallelization: employ multiple numeral systems (e.g., base 7 and base 10) concurrently to compute repdigit anchors and their triangular numbers; each base yields its own sequence (e.g., 3300, 333000, 33330000 in base 7).

2) Task-levelparallelization: assign independent jobs to disjoint ranges of repdigit or non-repdigit inputs—one process might handle values starting at 3300 while another begins from 33333333330000000000—so anchors and subsequent additions can be generated concurrently.

3) Pattern-iterationparallelization: treat each pattern length (for example 3300, 333000 or 33330000) as a separate work unit that iterates the additive sequence ( 1 + 2 + 3 + ⋯ ) in parallel.

4) AnchorsearchonGPUs: use digit-length heuristics and binary search operations to locate the nearest repdigit anchor for a given input in a massively parallel fashion on GPU hardware.

5) Independentpatternassembly: construct the left and right pattern blocks separately on GPU threads, allowing simultaneous assembly of both halves of the triangular number.

6) Parallelreduction: break the digital-root reduction into hundreds or thousands of small computations across the GPU to obtain the scale-dependent key quickly.

7) Block-wisebaseconversion: split large base-b numbers into smaller chunks, convert each chunk independently on the GPU and reassemble them to perform base changes efficiently.

8) Parallelnon-repdigitprocessing: apply logarithmic or block-based techniques to non-repdigit triangular numbers so they can be processed alongside repdigits without serial bottlenecks.

Overall, the objective is to decompose the computation of T n = n ( n + 1 ) / 2 into schedulable parallel tasks, including string assembly, anchor generation, reduction, and other bounded arithmetic operations that can be distributed across GPU threads. In this way, work that would traditionally be performed through a largely serial large-integer pipeline can instead be reorganized into smaller independent components better suited to multi-threaded GPU architectures. With careful implementation, triangular-number generation may therefore be expressed as a parallel workload in which non-dependent stages are executed concurrently to improve throughput and reduce computation time.

B.2. Logarithmic Enhancements

1)Auto-generatingverticalconstantsfrominheriteddigits(Figure 2): This approach could generate vertical constants automatically, eliminating the need to manually identify them in each base and enabling dynamic formation of these constants for pattern assembly in large-base systems (e.g., base 1000). Since the composition of the horizontal patterns is also linked to the vertical patterns, it may be possible to discover a logarithmic characterization for these relationships as well.

2)Derivingtheremainderviathepatternindex: This approach can reduce computation time compared with computing the remainder directly as r = N L / R mod P ℓ . The scalable reduction method yields the digital root of a large repdigit, which is mapped to a pattern index drawn from the nine repeating values { 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 } (see Figure 3). The remainder could then be obtained by subtracting 1 from pattern index directly without additional computations.

3)Speedingupscalablereductionviacaching: The scalable reduction step dominates the runtime of triangular-number generation, so accelerating it can substantially improve overall performance. In addition to parallelization (e.g., multithreading or GPUs), the repdigit setting enables an effective caching strategy keyed by digit and length. This caching approach has already been implemented, and the benchmark results reported in this paper reflect the corresponding increase in speed. For example, to compute the digital root of the repdigit N = [ 2 ] 140000000 , it is unnecessary to iterate over 140,000,000 identical digits. Instead, one can cache the contribution of fixed blocks of repeated 2’s—for instance B k = [ 2 ] k for selected lengths k (e.g., k ∈ { 10 3 , 10 6 , 10 7 } )—and then express 140,000,000 as a sum of these cached block lengths (e.g., 140,000,000 = 10 × 14,000,000). The digital root is then obtained by combining the cached block contributions rather than summing digits individually. This optimization relies on the uniform structure of repdigits and is generally not feasible for non-repeating digit strings.

B.3. Configurable TLV Channels for Future Work

1)Authorizationchannel: A natural extension of the authentication channel is an authorization channel. In this setting, TLV would not only confirm that a client has established a valid session, but would also verify that the client is permitted to perform a specific protected action. Accordingly, a TLV authorization channel is best interpreted as a second verification profile layered on top of successful authentication, where the final layer commitment is bound to operation-specific or resource-specific access conditions rather than to identity alone.

2)Documentaccesschannel: A second future direction is a document access channel. Here, the layered verification process would gate retrieval of protected content, decryption material, or indexed ranges within expanded catalogs generated by methods such as tri_matrix_stream. This is a natural fit for the catalog-oriented structure developed in this paper, since TLV already supports bounded windows and selective local extraction rather than requiring full-object processing in every step. In such a setting, a successful channel verification could authorize access to a specific document segment, key fragment, or retrieval range within a stored catalog-backed object. The most realistic interpretation is therefore controlled document access and selective retrieval built on catalog storage, rather than treating TLV itself as a general-purpose document storage system.

3)Distributedtransactionverification: A third future direction is a distributed transaction verification profile for blockchain or ledger-linked systems. The intended role here is not consensus replacement, but synchronized verification of transaction-related state, private payload access, or approval logic across distributed participants. In this setting, the TLV channel would act as a structured verification layer whose bounded catalog accesses and folded per-layer commitments are shared across a distributed workflow. This is especially relevant in architectures where subsets of participants require selective visibility or selective validation of protected state, since TLV naturally supports bounded local extraction and final-only acceptance.

Researchdirection: These examples suggest that the main reusable object in TLV is not a single authentication procedure, but a configurable layered verification profile. Future work may therefore formalize a family of TLV channels in which the same catalog and layer abstractions are retained, while the acceptance rule, protected object, and state-rotation policy are specialized to the intended application.

Towards the end of this paper, we leave with this final statement:

There is a symmetric structure in which every repdigit’s triangular number in any base also corresponds to a different triangular number in another base, as demonstrated. This symmetry arises from repdigits, which are themselves symmetric. We hope that these pattern-assembly methods may inspire innovations across multiple scientific domains.