** !!!! NOTE: The following servers will be Monday - Friday !!!! **

** !!!! if any support is needed, please email jp@aochain.net !!!! **

Name Access
Bank 1 Banco dei Medici AOCHAIN_BANK1
Bank 2 Banca Monte dei Paschi AOCHAIN_BANK2
Central Bank Central Renaissance Bank AOCHAIN_CENTRALBANK
Notary Notary Corda Client RDP

Whenever we design a system to maintain the ownership of assets (custody and deposit), we find many complex scenarios with multiple permutations of possible owners, underlying processes, and everchanging regulations by industry and type of asset. But there is increasing pressure to make all exchanges more fluid at the cost of relaxing some of the constraints set by regulation or the validators. How can we move to a world that is flexible, decentralized, autonomous, without losing the assurances that gives us that our assets can only be sold with our consent? The answer is a combination between workflows designed to speed up the processes, whenever possible, for the old organizations, while bringing access and transparency to the general public. We can accomplish that by using the advances of cryptography tied up with a flexible assignment of objects and owners via tokenization.

Our system is designed to maintain warranties and make sure that during an exchange of valuable goods (a.k.a. transaction), whomever is selling has the title to sell, whomever is receiving is in agreement of the terms of the Exchange, and that that the organizations signing the exchange have performed all tasks, manual or programmatic, with or without human intervention, that makes the contract valid and the participants whole. Our solution allows to match all that complexity with a common set of tools.


All Over Chain has worked and researched tokens as emoluments, since the early days of ERC20 and airline miles programs. We have exchanges of value and clearing transactions all the time: when you place an order online, your money is debited, and the transaction can only be completed once the logistic “fulfillment” finishes successfully. Moreover, when you purchase an item on back-order or has warranty on an electronic device, you are also using representation of “value” (tangible in the case of the fulfillment, and contingent in case of the warranty). But all these operations occur behind the scenes. We, the customers, don’t realize all the complexity behind of a claim, a rebate, or issuing and exchanging food stamps. Everything we do the representation of something else; the use of money could be modeled as a reciprocal altruism.

We worked on All Over Chain v1 when Hedera Hashgraph was announced; I programmed a Swirlds interface to enhance one of the demo examples included in the SDK, and after Hedera18 invested heavily in a platform for Digitalization, Custody and Exchange of assets. Unfortunately, we were too early. In the regulator’s mind, minting tokens was equivalent to forming Ponzi schemes. Furthermore, the platform that we selected was the Smart Contract on Hedera, and although the initial PoC showed it offered the throughput we expected, the Council capped the gas per contract and size of the state per contract. With all those problems, our stockholders lost interest and sold their shares; we had to restructure the company, include new lobbying lawyers and sales effort to exchange ideas with to the regulators in Latin America, and then Covid. Too many problems converged at once.

But when Hedera announced HTS, a new glimpse of hope opened. I can repurpose many features of the AOChain v1, plus add the new developments in Digital Identities, Mirror Nodes, and the prototypes built by Hedera’s team for Corda and Hyperledger. I was ready for taking a fresh look at Hedera Hashgraph, and started putting some ideas together for the H21.

What it does

The platform integrates Corda OS, Hedera services for account management and token issuance, transfer, and redemption (burn). Also proposes a new mechanism to manage identities, separating the owning of the keys to the accounts associated with it.

By using Polkadot{js}, we can centralize the private key ownership in a single Chrome extension, while granting access to three (and possible more) networks. Finally, the project proposes a payment portal mechanism for any eCommerce, running on a static server, that proposes a new “Access Token” to validate payment using short-lived hedera accounts and issues tokens when the user “purchases items” that have a “out-of-stock” status (aka. backorders).

At the end, the platform merges some concepts presented with the introduction of the Hedera Consensus Service, with the transfer and custody of other type of property earmarked by holding these tokens; some of the tokens represent an one-to-one image of those existing in Corda (like those seen in the demo), but could be modified in value and signatories to preserve the privacy of the parties involved. Overall, the token transfer serves as a real-time updates about the progress of the approval inside the private network.

How we built it

The most cumbersome part to build was the integration with Corda. The exchanges with the peers and notaries, plus the fact that it runs with older JDK8. But both Hedera and Corda have excellent documentation; and yet the question remained on whether to send all the payload inside Corda, and then extract and forward at the notary, even relaying with other peers as signatories to the “legs” that a swap transaction has in other ledgers or networks; what about including manual approvals? Yes, that was another use case. The challenge was to use Corda as a messenger to pass on the payload provided by Hedera, and then at the last step, the Notary was responsible to execute. Also, since there could be multiple participants, to collect all the signatures needed to make a transaction in Hedera, without the signatories to be online: a “Store and Forward” mechanism for Hedera. The idea started after seeing the Corda repo with HCS, that did not include the Validating Notary scenario, nor was prepared to restore the Notary under failure: If the notary fails, how can you restore the workflows that are in-flight? Well, you have to rely on local databases or an external network that is as performant as a private network (Hedera).

The next question was authentication. The Chrome extension that we used in version 1, Composer, was retired from the market, and only brought to my attention by a customer of mine that could not access his tokens (that by the way is moving to the Hedera Token Service). My research showed that ED25519 was supported by Polkadot, and that the extension was open sourced. After some tinkering, we got to work the relay from the twelve-word seed, that was recently supported by Hedera to support the BRD wallet.

With all the backend solved, the task was the frontend. Corda had a template for API and UI built on Angular and Springboot. I took it and adapt it to the scenarios, that started as an I Owe You (IOU) model, but evolved into logging databases and the user repository to host the account private data. Last, I had to put together a query to get data from Hedera (paying Hbars), and mix it with our local data. Unfortunately, this “matching” engine was not completed to submit within the repo.

With all that sorted out, it was time for deployment. I sent the static shopping website in Google Cloud, not before learning how to create a container, load data using the shell, and issuing certificates from another website. Overall, that was a very nice experience. The rest of the servers are local, and the biggest ones in AWS, but could be containerized and sent to Google Cloud as well.

At last, I am recording videos and filling this application wishing we get some recognition.

Special Notes:

@Google Cloud – Financial Services. We use it to host static webserver with a certificate issued by google (routing), provided and approved by the domain owner.

@UCL. Tokenization protocol Challenge. Our platform is asset agnostic and can be modeled to map any of the traditional “tokenization” scenarios, plus the new ones involving low fees and high throughput (like food stamps, or loyalty rewards). Corda offers the option to move attachments internally, and through Google Cloud and/or Hedera File service, we could expose the to the outside world.

@Armanino. Wrapped Token Challenge. The wrapping of tokens and movement across networks relays the control in the “bridges” and validators. Since we have some preliminary efforts to wrap tokens using cryptography, the most successful stories are with central institutions that work as a guarantor of the transactions occurring in both networks. This is precisely what these tokens could be used in Hedera (those tokens that now only give access to the banks in the network could be tendered to the general public). This is the equivalent of a regular bank offering “USD -C,T, etc.” into Hedera, and the equivalent redemption in other networks.

@DLA Piper& BCW Group. I think that the developments presented in our solution can be used by your current offering. I have written some use cases in my future book: “It’s all about consensus”, that will be published in May. I would love to discuss some of my ideas with you.

Challenges we ran into

Solitude. I proposed to two other colleagues to join the team, but they were already committed with something else. I then decided to start building the solution myself. At the end it was a very lonely ride! The upside was the support form Greg and Cooper. As always, the Hedera Team was the best part of this experience.

Accomplishments that we're proud of

The validating Notary connected to Hedera is a big win. It keeps the traditional State control, but now contrasts with the tokens publicly available. Also solves a big problem for all the Central Banks that are exploring Corda as their platform for CBDC, with an ever growing size of the UXTO of un-redeemed issuances.

The capability to extend logic beyond Tokens and include self-executing code and portable transactions wrapped in a message that can be dispatched by the Notary is a very promising development in distributed computing. In addition, the capability to extended orchestration with other networks, and “wrap” assets within a Hedera token. The whole model facilitates all scenarios of fiduciary and delegated trusted relationship among individuals and organizations.

The homologation of Polkadot addresses with the Account Management engine of Corda, and the multi-signature capabilities of Hedera are another area that can be of interest.

What we learned

Google Cloud Service is at par with the AWS offerings! I need to do some cost analysis, but the service offering makes perfect sense for some costumers.

I re-confirmed that Hedera is a great platform. I still proclaim that the scenarios managed through this platform will reshape many Enterprise Application architectures.

What's next for All Over Chain v2

Unfortunately, we ran out of money last year. As of January, the option was to liquidate and sell the assets, including our SAP banking licenses; personally, the guideline was to find a job.

But then H21 comes along. Getting the prizes and recognition that is behind our platform will boost the sales and will be the rebirth of All Over Chain Inc.

Yes, HTS is very promising. I expect a swarm of offers as soon as people see what we’ve put together. Who knows? maybe this is exactly the way things were meant to be, and we merge AOChain v1 with AOChain v2, and relaunch under the good augur coming from winning Hedera21!

Built With

Share this project: