MintChip works in a request-response fashion.
The person who want money needs to create a request. (the request basically contains the MintChip ID and a Nonce, Nonce optional)
The person who send the money "signs" the request, which causes the mintchip to deduct money from the secure tamper-resistant storage.
The mintchip now produces a "response" ONLY valid for the mintchip who sent the request. The requester imports this response in his mintchip, causing the mintchip to increase the money in the secure tamper-resistant storage.
This is what is creating MintChips double-spending protection, without need to publish any ledger, since signing a request spends money, and the same response cannot be imported twice in the same mintchip since mintchip saves the Nonce of each response to its secure memory. Even if ambigious mintchips does not know the Nonce of all other mintchips, it will not accept a transfer destined for a another mintchip, thus you cannot send the same "coin" to 2 mintchips.
Whoever who writes the request can freely select the "Nonce" value, and writing a request does not need to use the mintchip, eg anyone can write a request.
The payer can change the Nonce value at will, but its important that the Nonce is unique across transactions of the same value to the same receiver, else you will burn money since the receiver cannot import a already "spent" nonce.
I think it can be done in a similiar way to this:
https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chainsBasically, a secret must be selected, such so the sender of mintchip-currency needs to publish the mintchip-currency in the blockchain, to redeem his bitcoins. The owner of the receiving mintchip only needs to scan the blockchain and then import the message in his mintchip.
The problem is that this require RSA PKCS#12 certificate checking against MintChip CA certificate.
Try to figure out something.