A Corda platform állapotai leginkább a klasszikus szerződésekkel állnak kapcsolatban. Az állapot egy szerződés legfontosabb tulajdonságait és a szerződő feleket írja le programozott módon.

Fontos megjegyezni, hogy ez nem teljesen ugyanaz mint a klasszikus blokklánc rendszerek okosszerződései. A Corda platform elsősorban a klasszikus jogi szerződéseket próbálja megfogni a pénzügyi szektorral konform módon.

Például egy ilyen szerződés szólhat egy fizetési kötelezettségről (IOU), amiben Alice garantálja azt, hogy egy bizonyos mennyiségű összeget fizet Bobnak egy lejárati időpontban. Ebben a példában a szerződésben résztvevő felek Alice és Bob, az állapot tulajdonságai pedig lehetnek az összeg mennyisége, a fizetési határidő vagy a büntetési kamat nemfizetés esetén, hasonlóan az alábbi ábrához.

Fontos különbség a Corda és egyéb blokklánc rendszerek között, hogy a Corda-nál nem a kód a “törvény” (code is not low). Minden egyes állapot – ami egy klasszikus szerződésnek megfelelő digitális entitást ír le – kiegészíthető egy klasszikus szövegalapú szerződéssel az úgynevezett jogi prózával. Ez a szerződés egy jogi szerződésnek tekinthető, aminek fontosabb paramétereit az állapotot leíró objektumból nyeri.

A Corda főkönyvének két fontos tulajdonsága van.

Egyrészt alapvetően hasonlít a Bitcoin blokklánc felépítéséhez, ahol az aktuális főkönyvi állapotot az úgynevezett el nem költött pénzérmék segítségével ábrázolják (UTXO). A Corda platformon nem érmék vannak, hanem állapotok, amik gyakorlatilag szerződéseket reprezentálnak. A főkönyv ezeknek a szerződéseknek az evolúcióját írja: amennyiben egy szerződés megváltozik, egy új állapot jön létre, új paraméterekkel és a régi állapot automatikusan történelmi állapottá válik.

Például az előbbi tartozásos példát tekintve, ha Alice tartozott Bobnak 10 fonttal és abból visszafizetett 5 fontot, akkor a szerződés aktualizálásra kerül. Ez technikailag azt jelenti, hogy az eredeti állapot, ami a 10 fontos tartozást írta le, történelmivé válik és egy új állapot jön létre, ami egy 5 fontos tartozást ír le. A teljes rendszer aktuális státuszát a nem történelminek nyilvánított állapotok írják le.

A másik jellegzetessége a Corda főkönyvének, hogy nincsen se globális főkönyv, se globális üzenetküldő szolgáltatás a rendszerben.

Általános blokklánc platformoknál a főkönyv a rendszer minden egyes csomópontjánál replikálva van, ami nagyfokú biztonságot eredményez. Ehhez hasonlóan egy új tranzakciót egy általános üzenetküldési mechanizmus (global broadcast) a rendszer összes csomópontjára elküldi és a rendszer összes csomópontja validálja a tranzakciót.

Ezzel az a probléma, hogy a tranzakció, illetve a főkönyv adatai mindenhol kvázi publikusan letárolásra kerülnek. Ez viszont sajnos a legtöbb pénzügyi és banki környezetben nem elfogadható.

A probléma megoldására többféle kezdeményezés létezik. A blokklánc közösségeken belül, általában korszerű kriptográfiai algoritmusokkal, mint például zkSNARKs vagy STARKs, próbálkoznak.

A Corda ezzel ellentétben egy másik megközelítést alkalmaz: egyetlen globális főkönyv helyett úgynevezett biparty és multiparty tényeket használnak, amelyek csak bizonyos csomópontoknak és szerepköröknek láthatóak.

Például az alábbi ábrán 9 tényt láthatunk, amik különböző szerepkörök között vannak szétosztva láthatóság szempontjából: az 1-es és 7-es tényt például csak Alice és Bob láthatja, a 3-as tényt Carl, Ed és Demi, stb.

A tényeket a rendszer állapotai, pontosabban az állapotok típusai reprezentálják. A globális üzenetküldés helyett pedig a platform csak azoknak a csomópontoknak küldi el az adott információt amelyeknek feltétlenül látniuk kell (need to know protocol).

Természetesen ez nem számít olyan biztonságosnak konszenzus szempontjából mint egy globális üzenetküldésen és főkönyven alapuló nyilvános blokklánc hálózat.

Fontos azonban megjegyezni, hogy a Corda protokoll nagyon szigorúan konzorcium környezetben működik, ahol az egyes csomópontok enterprise cégek, jó eséllyel bankok belső hálózatán futnak.

A platform alkalmazás logikája – amit más blokklánc rendszerekben az okos szerződésekkel valósítanak meg –  Corda esetében tranzakciókkal valósul meg.

A tranzakció felelős azért, hogy egy állapotból egy másik állapotot készítsen.

Az előző Alice és Bob közötti 10 fontos tartozás példánál maradva, ha Alice 5 fontot visszafizet, akkor azt egy tranzakció segítségével teheti meg. Ez a tranzakció egy új állapotot hoz létre, ahol Alice csak 5 fonttal tartozik Bobnak és a régi állapotot pedig a történelmi címkével látja el. A valóságban ezek a tranzakciók jóval bonyolultabbak is lehetnek:

• Elképzelhetők tranzakciók bemeneti állapot nélkül, például amikor egy teljesen új követelést veszünk fel a rendszerbe.
• Lehetnek tranzakciók, amiknek nincs kimeneti állapota. Például, ha egy létező követelést teljesítünk, azzal gyakorlatilag egy létező digitális eszköz megszűnik.
• A tranzakciók épülhetnek több bemenő állapotra és létrehozhatnak több új állapotot is.

Egy tranzakció érvényes vagy nem érvényes volta is többféleképpen megvalósítható. Általánosságban egy tranzakció érvényes, ha az összes szerepkör aláírja, melyeknek a bemeneti vagy kimenő állapotokat látniuk szabad. Ezt azonban általában kiegészítik adott tranzakciós típustól függő egyedi validációs logikával.

Számos egyéb komponenst tartalmaz a Corda keretrendszer, melyek talán kevésbé jelentőségteljesek mint az eddigiek, de mindenképpen érdemes megemlíteni őket.

Ilyen például a külső adatforrások hiteles integrálására szolgáló orákulum csomópont (oracle node), vagy a tranzakciók hitelesítésére és főkönyvbe való beírására szolgáló jegyző szolgáltatás (notary service). További érdekességként érdemes megemlíteni, hogy az egyes csomópontok közötti pontos kommunikációs protokoll alkalmazásról alkalmazásra testreszabható az úgynevezett Flow keretrendszer segítségével. Így teljesen egyedi alkalmazásspecifus workflow-k és processzek is megvalósíthatók.