Performance 
Memory footprint
All sizes provided below may be adjusted depending on project's parameters. As of july 2025:
| Service | Size | Comments |
|---|---|---|
| Kernel | 1.5 kb | Average size. May vary depending on ICS. |
| Entry Point | 6.0 kb | Corresponding to 7 kernels, 4 aid per kernels, and 10 selected combinations for a given card's PPSE. Support of issuer scripts and entry point data exchange. |
| Service Manager | 37.5 kb | Corresponding to a database storing references to 3-byte long tags and their properties from 12 different classes, and a list of 30 records to manage ODA (signed read record). |
| HSM | 19.5 kb | Corresponding to 60 public keys and 500 revocated certificates (100 per RID). Eventually, these assets may not be stored in ram because ODA verifications occur outside the performance time frames. |
| Reader | 9.5 kb | Corresponding to a sred data structure to manage sensitive data. |
Additionally, switstack moka requires 2 memory buffers:
1. 1 storing acquirer's supported combinations for a given transaction type. This depends on the number of supported kernel, the number of AID per kernel
2. 1 storing all the tags coming for the selected combination and the card that are processed
Additionally, it requires some space to store public keys (6 keys per RID in production).
For certification sessions, these requirements are a little bit higher as some RID may need up to 12 keys, and a logger may be used.
For development, the integration of virtual cards adds a 8.5 kb.
As explained in the next section, what's cost the most (service manager) is the comprise between having the best timing and allocation static memory. Considering that contactless EMV Level 2 certifications are very demanding in terms of timing, switstack moka prioritizes processing time over static memory.
Timing
A contactless EMV Level 2 stack may be described as following:
- It is a state machine;
- It transitions from one state to another by mainly interpreting TLV streams:
- The initial state is provided by a TLV configuration;
- The final state is represented by a series TLV encapsulting the transaction outcome.
- Intermediate states are specific to each payment network, and match brand's logics. These logics don't cost much in term a transaction time given the fact the RSA computation is performed once the NFC card is removed from the field (excepted for the Interac debit network
).
Hence, the best EMV Level 2 performance will be achieved when TLV structures are efficiently managed (i.e. multi-threading doesn't solve any problem). That is why switstack moka's TLV parsing lies on static allocation to avoid costly lookups. That way, EMV tags can be directly accessed.