When you throw it and it comes back, its called a boomerang. Boomerang also happens to be the internal codename for the securities exchange engine powering gTrade. But lets wind back a bit. Securities exchanges are traditionally distributed systems. While we typically associated “distributed” with clustering, fail-over, scalability and so on, “distributed” in this case is not to be interpreted in a good way. All it means is that any single component within the traditional exchange infrastructure is too brain-dead to facilitate an exchange on its own. This is not so say that there are no provision for redundancy, en contraire, but this is achieved by clustering many instances of the same… brain-dead… component. So what does it mean, to be “brain-dead” then?

A distributed system is one made of a number of physically disparate components working together to achieve a common goal. That’s where the definition stops, and where confusion begins. You see, there are two ways you could achieve what I’ve just stated. Suppose you were building a distributed system that needed to perform tasks A, B and C. Alice could build three components, each performing the roles A, B and C respectively and networking the three. To achieve redundancy, she could run two instances of each of the A, B and C components, and networking the six. Wally, on other hand, could built a single, albeit more sophisticated component that could simultaneously assume the roles of A, B and C, i.e. it could handle all three tasks. For redundancy, he could run two networked instances of this component.

At the end of the day (month?… year?) both Alice and Wally have themselves a distributed system. Which is better?

Let’s consider an order that needs to be processed by each of the functions A, B and C in some sequence. Alice’s system would delegate the order to one system, then migrate it on to the second and, finally, to the third. Because the systems are networked, the network delay cannot be taken out of consideration, and the turn-around time would be substantial, regardless of the throughput capacity and present loads on the servers. Wally’s system could facilitate the order within the confines of a single server. Sure, the load on the server would inevitably increase, hampering the capacity to process subsequent orders, but with proper load balancing we can simply spread the orders across the remaining servers, adding servers as we need to.

Back to the original question. Which is better? At this point an overwhelming majority of literature on architecture and computer science tries, in order to be seen as politically correct, to take a neutral stance on the two solutions. “There is no correct answer…”, they would say. “It all depends on…”, they would add. Hell NO! Not here! Not on this blog! Wally’s solution is better hands-down, regardless of which way you look at it. Why? Because his avoids unnecessary network hops that plague today’s distributed systems, spreading functionality across nodes purely for the sake of looking and sounding “distributed”. The result, you guessed it: “brain-dead” nodes that are incapable of standing on their own two feet and accomplishing anything in the absence of their peers. Wally’s is distributed in every regard, yet it can run with as few as a single component.

How does this relate to a securities exchange (SE)? SEs for various historical, political and commercial reasons have erred on the bad side of the distributed paradigm. There is a separate match-up engine, a clearing house and a stock registry. Not to mention the various brokerage systems that cloud around the SE because everyday investors simply aren’t admitted directly into an SE infrastructure.

The Boomerang engine backing the gTrade securities exchange does everything you’d expect of a stock exchange: a proverbial “shampoo and conditioner, all in one bottle”. The clustering aspect, along with the benefits of scalability and redundancy is outsourced completely to DTS/S1 ‘Pitch Black’: a native Java transaction-oriented object database from Obsidian Dynamics. While it is less than a year old, and not yet available to the public, DTS/S1 has already proved its worth. DTS/S1 allows applications to manipulate plain old Java objects in a way that is isolated, durable, atomic and consistent, as you would expect of a transaction processor. DTS/S1 supports the ’serialisable’ level of transaction isolation, which is the highest level of transaction isolation achievable. Simply put, you read and write to your Java objects as you would, and those changes are persisted to permanent storage without any further intervention on your behalf. More so, the changes are documented in an audit log and can be traced at any later point in time. What were the changes? Who made them and when? DTS/S1 can provide the answers when asked. Most beneficial to Boomerang is the fact that DTS/S1 is clustered internally. It runs on as many (or as few) compute nodes as required, and can write data to a clustered NAS. And its fully transparent: Boomerang still thinks that it runs on a single machine.

The gTrade business model, and hence the Boomerang workflow, is based upon a two-phase company lifecycle. Let’s come back to this later. A traditional stock exchange facilitates the trade of equity in a publicly listed company. That is, it assumes the company has made its public offering and the brokers have distributed the shares among the interested investors. Some investors eventually express a desire to sell, while others are poised to buy. This is all well and good for a well-established company, but what does this do for a start-up? The short answer is nothing. Start-ups are on their own when it comes to gathering the initial capital and working hard for a number of years to get to a point where they are fit for public listing. This also happens to be the exit point for private investors, such as Venture Capitalists who have chosen to invest in the company from the outset.

gTrade allows for everyday investors to “subscribe” to a start-up by purchasing a number of shares at a fixed price. A start-up company that passes the necessary due diligence and is considered by gTrade to be fit for listing will “expose” a part of the company for public investment in exchange for cash which is used to bootstrap the venture. For example, company StarSoft might be willing to forfeit a 40% share in return for $100,000 in cash. They could break up the public share into 100,000 tradable class A shares, fixed at $1 each. StarSoft would be listed on gTrade and given, say, 3 months to raise the capital. Investors choosing to opt-in would “subscribe” to the shares at a fixed price per share. Remember, the clearing house and the stock registries are integrated into Boomerang, allowing it to hold both the shares of StarSoft and the investor’s money in escrow, until the company is fully subscribed. In that event, Boomerang will transfer the shares to their new owners, and the cash to the proprietors of StarSoft. On the other hand, if StarSoft fails to gather sufficient investor interest by the nominated due date, and the latter is not extended, Boomerang will recover the subscriptions by yielding the cash funds back to the investors and forfeiting the shares back to the start-up, in effect reverting all that has happened within that seeding round. The favourable outcome for everyone is, of course, that the company manages to fully subscribe and the initial cash-for-stock trade is settled. At this point, and for this particular seeding round (for there could be several rounds), Boomerang switches its mode operation to a conventional, fully-automated stock exchange, not unlike NASDAQ.

Boomerang’s fully-automated matching engine and the integrated registry allows investors to trade shares in real-time, and to receive and/or forego stock and cash the moment right after the exchange has been facilitated by Boomerang. And because both the stockholder registry and the clearing house are intrinsic parts of the trading platform, Boomerang allows for optional cash and mandatory stock reservations to guarantee delivery after an exchange takes place. One of the key differentiators of an integrated systems is that activities such as naked short selling can be eliminated in their entirety. At any point in time, Boomerang is fully aware of each of the investors’ holdings, including both cash funds and their tradable stock and subscription portfolios. This allows the punter to make optional cash reservations for buy orders, ensuring his/her transaction succeeds given a matching sell order. At the same time, Boomerang applies mandatory stock reservations for all sell orders, ensuring that stock is in the physical possession of the seller, thereby guaranteeing delivery. This removes the possibility of an unscrupulous investor or stock broker from orchestrating a naked short sell.

At gTrade, there is no decoupling of the investors and their holdings. This includes their cash funds. In addition to maintaining an investor’s personal information, their investment history and their stock and subscription holdings, gTrade houses what is arguably the investor’s most treasured possession: their wallet. You cannot complete a subscription or a buy transaction without having some prior funds in your wallet. Similarly, when a sell transaction completes, money will be deposited into your wallet. On the outside, you interact with your wallet by depositing and withdrawing money; you can “top up” and “sip off” from your gTrade wallet at any time. A wallet can be seen as a pool of money that can be invested, and into which the capital gains from the investments flow. There are times, however, when not all of the money you have in your wallet is “available” for investing. This occurs if you have chosen to reserve funds in a previous transaction. For instance, suppose I have $1000 in my account, and I’m in desperate need of 100 shares of XYZ and I’m willing to pay at most $1 per share. I could put in an unreserved buy bid, and providing a willingful seller emerges I have at least $100 in my account at the time of the exchange, the purchase will go ahead. But suppose I’m engaged in multiple buys and sells at the same time: money is flowing in and out of my wallet and while I’m doing quite nicely, there is no guarantee that there will always be $100 in my account to facilitate this “special” trade, and when the right seller emerges, I simply might be out of cash.

gTrade’s Boomerang engine has facilities available to exercises more fine-grained control over your buy orders should you decide that certain orders are more important than others. In the previous example, I could have reserved $100 (or less) for this trade. This amount would still reside in my wallet, but be locked to all other operations but that particular buy order. Funds reservations are a very powerful feature of gTrade, however, they’re somewhat restrictive in that they lock down a portion of your funds. To make this feature more appealing, we have enhanced it with what we call Early Funds Release (EFR). EFR is a mechanism that reduces the amount of reserved funds to an absolute minimum, and continuously re-evaluates the reservation figures, optimising them for your current buy position. EFR is best explained with an example. Suppose we have reserved $100 for an at-limit purchase of 100 shares of XYZ at $1.00. Later, we’ve been fortunate enough to find a seller who’s willing to part with 50 shares at $0.80. We’ve acquired 50 shares, spending only $40 out of our reserved $100. After the trade, Boomerang will evaluate our current position. It will see that we’ve still got 50 shares to fill the order, which will cost at most $50, given our initial limit. Yet we still have $60 left of the reservation. Boomerang will then release $10 back into the available portion of our wallet to be used immediately with any other offer.

Finally, I would like to point out that while gTrade will at some point support external brokers via a public API, the integrated nature of the platform makes its features available to the public through our Web desktop, which we have apply named “Webtop”. Webtop is our AJAX-based rich client that takes stock trading to a whole new level; not yet complete, but well on its way, and we hope to show it off in a couple of months.

Emil Koutanov
Chief Technologist and co-founder
gTrade

In order to build a stock exchange and trade investors money, you really need to be sure of the transaction engine underlying the platform.  gTrade utlises the next generation of transaction engines to ensure not only performance and reliability, but also meet the extreme regulations imposed by the Investment Protection bodies such as the SEC – this includes things such as the retention of data and its auditability.   You simply can’t do this with your run of the mill MySQL database and Ruby on Rails application – no matter how well you implement the system.   Don’t get me wrong, the LAMP (Linux + Apache + MySQL + PHP) & MARS (MySQL + Apache + Ruby + Solaris/Linux) stacks are great.  They are better than that, they’re excellent – totally revolutionised web development.  However, those types of stacks were never designed from the ground up for an enterprise implementation – this is evident from the great efforts needed to cluster MySQL and make RoR highly available – often ending in failure or extremely complex and rigid implementations.

This is where gTrade differs – we use Obsidian Dynamics’ DTS/S1 ‘Pitch Black’.  DTS/S1 is a next generation distributed transaction server and native object database. Pitch Black is a clustered solution that embraces high levels of parallelism to achieve absolute reliability, fault tolerance and organic scalability resulting in ultra high performance transaction processing. Parallel to this, Pitch Black achieves the lowest cost per transaction of any other commercial transaction processor or transactional database management system.

Pitch Black is all about simplicity and speed. Where relational databases bear the overhead of ‘unpacking’ complex object-oriented structures to fit a 2D table model, and then ‘repacking’ these structures to present back to the application, a native object database persists business structures as-is. The net effect: where peer products require million-dollar computer hardware to achieve speeds in the order of tens of thousands of transactions per second (TPS), Pitch Black can achieve similar figures on hardware that would take up one unit of rack space. Given clusters of high-end server hardware, coupled with clustered network attached storage (NAS) devices, speeds in excess of 100,000 TPS are achievable.

DTS/S1: features

Clustered deployment

While Pitch Black has been designed to extract blistering performance from a minimal deployment, it has been engineered for growth. Pitch Black assumes an N x M (N-by-M) compute and storage model, where N clustered DTS/S1 nodes operate on a shared storage facility that may internally be clustered to M nodes. Although not novel, a modular shared-disk approach is far more applicable to systems such as DTS/S1 which advocate the proximity of business logic to storage. Its elegance is in allowing an organisation to scale either its computational power, or storage capacity, or both, whichever proves to be the bottleneck. This level of scaling is a physical impossibility in a shared-nothing architecture, where each cohort is both a computational and a storage node.

Microcontainer architecture

Pitch Black employs a microcontainer architecture, which provides additional flexibility in the interaction between business logic and the storage subsystem. The microcontainer provides a number of services to the application, which include (predominantly) a transaction service, resource locking and deadlock avoidance, querying (of both the overall state, historical state and the transitional data) as well as an external interface for exercising queries and invoking transactions remotely. A significant advantage of the DTS/S1 microcontainer is its ability to host and execute the full application business logic suite within DTS, and distribute the processing load throughout the nodes that comprise the Pitch Black cluster. Unlike stored procedures employed by most commercial databases, DTS does not lock the developers into working with proprietary languages that only the database understands. Because the DTS transaction and object broker service are native, the application developers are not required to learn any other scripting language. This paradigm extends to querying DTS – like any other aspect of the system, the queries are also written in the developers’ native language. Presently, DTS/S1 supports the Java(TM) programming language, including Java ME and Java EE technologies.

The DTS/S1 transaction service is subdivided into two layers – the (high level) transaction broker and the (low level) storage and interconnect fabric. The higher level facilitates the principles of the DTS model, including object revision control, decoupled transactions, recovery protocols, remote transaction and query brokerage, an API to interface with the business logic, resource locking and others. Its unaware of the interconnect and storage protocols that are provided by the pluggable interconnect fabric (PIF). This enables Pitch Black to support a variety of physical storage platforms, including storage area networks (SANs), network attached storage (NAS) serving a POSIX-compliant file system, non-volatile RAM (NVRAM) and FLASH technologies – any storage implement ranging from enterprise-grade storage farms to embedded systems.

The next level up in the DTS stack is occupied by transactions and queries. These are always defined on the DTS node in form of conventional Java bytecode. They may be either a part of the business logic that resides and executes on the DTS node, or “named” parametric transactions and queries that can be invoked remotely via the Remote Object Model Broker (ROMB) API through the external interface.

Like many other things, the DTS microcontainer does not impose structure on the external interface, which may be a pathway for communication with other components that form part of the system, or a B2B portal for external 3rd party systems.

Floating objects

We have christened the Pitch Black design model as a “floating objects” architecture. All objects in DTS undergo separate life cycles, however, operations may atomically combine fragments of certain objects’ life cycles in time. Although independently versioned, objects may reference others forming arbitrarily complex graphs. Because Pitch Black is clustered and each DTS node is inherently multithreaded, there are avenues allowing data to be viewed and manipulated in parallel. Recently accessed and modified objects are cached on each node, and cache coherency is maintained by each node.

The floating objects architecture assumes the transparent migration of objects from one node to another, where objects may simultaneously co-exist on multiple nodes for read-only operations. In order to accommodate this, DTS provides a re-entrant read/write lock service and deadlock avoidance mechanisms which are always employed by DTS/S1 but are also available to the application level. By comparison, relational databases are unaware of the individual objects that form the data tables. The only way serialisable transactions (the highest level of transaction isolation) are achieved is through row-level locking, which in all but the most trivial cases has to acquire a series of locks, as multiple rows across several tables may constitute a single object. This is largely uncontended synchronisation, where locks are acquired out of need. Being aware of the higher-level object context, Pitch Black contends for the minimal number of locks to achieve the same level of transaction isolation.

Decoupled transactions

The next design fundamental behind Pitch Black is decoupled transactions. Pitch Black records all data manipulations as transaction objects. Each transaction object depicts the change that one or a group of objects must undergo atomically. Should a transaction fail to update all objects in its working set, it will roll back all changes, returning the system back to the precise state it was prior to the commencement of the transaction. Pitch Black maintains a coherent cache that ensures that all nodes within the cluster are exposed to a consistent overall data state. The fundamental distinction between Pitch Black and peer transaction processors and databases, is that the latter tend to have monolithic data structures that encompass the overall system state and get persisted periodically.

In order to illustrate the difference between monolithic and floating object models, consider the following diagram that illustrates the evolution of an object in a relational data model. A relational data model depicts all data as a set of tables. Most enterprise business objects map to more than one table and, conversely, a single table depicts fragments of more than object. Relational databases operate at row level, and being unaware of the object schema cannot exercise revision control on a per-object basis. What we are able to observe then, is the evolution of monolithic structures in time, where each monolith is assigned a revision number following a transaction.

All transactions ultimately relate to the same monolithic data structure and must be replayed from the journal in strict sequence to rebuild a transaction-consistent view of the overall state in an event of a failure. During recovery, the system will first inspect its stable storage to locate the most recent image taken prior to failure. The image will then be loaded into memory and the system will re-evaluate each transaction recorded after that image up to the point of failure. Transactions that have not been marked as committed will be rolled back. Theoretically, after this process is complete the system will assume the same state as it was in just prior to failure.

Re-aligning a single object invariably involves a complete replay of all pending transactions – a process that takes minutes if the system was heavily loaded prior to failure. Pitch Black operates on a finite set of lightweight objects that can undergo independent versioning and may form completely isolated chains of transactions that may be replayed in parallel and out of relative sequence. This is illustrated in the figure below:

At first glance, we may be mislead in assuming that this diagram depicts a set of wholly interrelated objects. In fact, we can trace out two completely decoupled transition paths with no overlapping intermediate dependencies (red and green on the diagram). It follows that to recover object D from the initial set of objects, we only need to replay two out of the 5 transactions depicted in this graph.

Pitch Black employs a complex algorithm that builds a dependency graph and isolates non-overlapping transaction chains that are replayed on demand – depending on which objects need to be re-aligned with their true state. Compared to the traditional roll-forward replay model this is blazingly fast!

JIT recovery

The concept of decoupled transactions incidentally lends itself to the same observable behaviour as that of JIT compilation. Every other transactional storage facility employs an ahead-of-time recovery protocol, where the first post-failure action is to completely re-align the overall state with the journal. A system concurrently logging at a rate of 10,000 TPS, for example, falls behind the transaction-consistent state by precisely 10,000 transactions for every second that it delays synchronising the data images with the journal. When a failure occurs, the entire log is replayed. Because transactions are strictly ordered, the replay is performed sequentially, which forbids the system from operating until its state is completely re-aligned. Consider Pitch Black: although it can in principle, DTS does not materialise every single transaction from the journal into the object images. It is, in fact, flexible in how it synchronises the journal with the object images. The maximum allowable journal backlog can be tuned for higher throughput, which would ordinarily incur a significant recovery time penalty on every other system. Not for Pitch Black, where a decoupled transaction model enables it to operate on small fragments of the overall journal backlog to instantaneously recover only those objects that are needed at the time of the recovery. Remaining objects that are not required immediately following a failure can be recovered later, either on demand, or at the discretion of Pitch Black.

Apart from achieving unmatched throughput and near-zero recovery times, decoupled transactions have overturned the classic parallel computing problem: cache coherency. A high-throughput, single-node database has one problem to solve, that is, when to synchronise between the journal and the images. A clustered database is challenged by a second problem, when and how to update the object caches on its peer nodes (cohorts). Typically, this would involve some use of the communication fabric that provides the interconnects between the cohorts. Given a sufficiently high throughput, this places an immense load not only on the interconnect fabric, but also on the processing capacity of the cohorts. The JIT-recovery nature of decoupled transactions provides any Pitch Black node with an opportunity to generate a transaction-consistent image of an object without the participation of its previous owner. Faster-than-light transaction processing is here, and its black – Pitch Black.

DTS/S1: concepts

Pitch Black has been designed to unify all enterprise data storage requirements into a single, cohesive solution. We have achieved this by closely mimicking the heap allocation model of memory-managed development environments such Java(TM) and similar programming languages, and depicting similar object-lifecycle semantics in a persistent storage model. In plain terms, what this amounts to is the ability for application developers define classes as they normally would, instantiate those into objects, manipulate various fields and have those changes transparently committed to stable storage. The objects themselves are plain Java objects, potentially existing objects that already depict the business data, that have been enhanced by implementing a lightweight interface defined by the DTS/S1 container.

Pitch Black persists all data on an object-by-object basis, whereby each persistent entity is subject to separate revision control and system-wide locking. Because an individual object is so small by comparison to the entire organisational data store, DTS/S1 affords to make near-instant, permanent modifications to objects soon after it has committed transitional data to its recovery journal. Should one or more nodes in a DTS cluster fail at any point, the remaining nodes will absorb the increased load and provide immediate fail-over. The most recent transaction-consistent data state will immediately become available to the remaining nodes and the objects can be utilised immediately without incurring the penalty of a roll-forward replay.

Modified objects undergo revisions, where all previous revisions are retained and can be queried directly without reverse-replaying transactions to gain a historical perspective on the data. This is a yet another distinguishing factor that cannot be attained by competing products since they only store the most recent data image and a change log. Pitch Black can be configured to store checkpoint object images for each and every alteration of the data. Since data is checkpointed on a per-object basis, it is trivial to isolate areas of the system that may require frequent historical trend inspection, such as an organisation’s monthly sales/performance figures. These snapshots can be consulted directly, without the need to backtrack the journal or set up a separate data repository.

Two areas of computing have served as the primary influence for the design of Pitch Black. The first is managed-heap programming environments and adjacent technologies such as type safety, pointer arithmetic and garbage collection. Even JIT (Just In Time) compilation was not overlooked. This is closely approximated in how DTS stores and manipulates its objects internally. This also reflects how the application interacts with DTS.

The second area is revision control systems (RCS). A modern RCS, such as the popular Subversion, are highly transactional in nature. While they offer per-resource revision control, they also support bulk operations and an all-or-nothing atomic commit. These operations are fundamental in transactional object databases. But apart from these primitives, RCS systems expose historical views, differences and change sets. This is not the norm for transactional systems, but it is in Pitch Black.

Benefits of DTS/S1:

• Scalability in both the compute and storage planes: upgrade one or the other – whichever is the bottleneck in your business context.
• No-single-point-of-failure architecture: the failure of one node is mitigated by the rest of the cluster. Active nodes simply absorb the increased load up to their designated capacity.
• Load balancing: the business logic and transaction processing load can be distributed fairly among all nodes in a DTS cluster.
• All-in-one solution: Pitch Black accommodates arbitrarily complex object structures and large object collections. When financially committing to a new technology, an organisation must be sure that no hidden costs follow. Why buy three products when one is all it takes.
• Zero downtime: when other nodes take over from a failed node, the data is accessible immediately, without incurring a roll-forward replay. Thanks to floating objects and decoupled transactions, failover is seamless and immediate.
• Zero maintenance: no database administration, no tablespace management, no schemas, ever! Add or remove nodes on-the-fly, all while the system is online.
• Cross-platform and cross-filesystem compatibility: a Java virtual machine and a POSIX-compliant filesystems are all that’s required to run a Pitch Black cluster.
• Embeddable: micro edition ideal for embedded devices, desktop applications, games, CAD and other desktop and mobile applications with internal storage requirements.
• Performance: faster than greased lightning! 10 KTPS on entry-level server hardware. MTPS-scale at the higher end!
• Cost per transaction: plenty of headroom for expansion to tens of thousands of transactions per second on the same hardware that you started with.
• Tools: DTS Night Vision for developing complete back office solutions.
• Zero impedance mismatch: no abstraction layers to mediate between the business logic and the storage platform. Existing business objects can be persisted right out of the box: no ORM middleware required.
• Security and reliability: DTS/S1 is a fully-featured transaction processor. Pitch Black supports serialisable ACID transactions – the highest level of transaction atomicity possible. All objects undergo independent revision control and can be audited by appropriate personnel.
• Standards compliance: Pitch Black is compliant with the Java Transaction API (JTA) specification for transaction demarcation.
• Time to market: concentrate on developing business logic and user interfaces – DTS takes care of the rest. DTS/S1 supports agile software development right from the word go.
• Sustainability: decreased rack storage requirements, reduced power consumption and heat dissipation requirements.

Check out DTS/S1 at: http://obsidiandynamics.com/dts/

– Guy

Saving the Venture Capital Market

With the National Venture Capital Association (NVCA) releasing their report on their predictions for venture capital in 2009, some key points resonate with the driving forces behind gTrade.

The first point is the most obvious one – capital in drying up…. fast!
“While 96 percent of VCs predict that more venture firms will not be able to raise money in 2009, a lower percentage, 85 percent of respondents, believe institutional investors will reduce commitments to venture capital asset class.”

96% is a significant portion of the VC market.  This will result in a significant reduction in the number of investments being raised, and as a consequence the Web 2.0 engine of social sites will almost certainly grind to a halt.  This is where gTrade is targeting to help by raising capital from investors who have lost trust in traditional markets and would like to share their wealth with these emerging businesses with a vision of a nice return if the company succeeds.

The NVCA article goes on to say:
“While many existing institutional investors are struggling with their allocations and future investment decisions, we will see new limited partners, many from overseas, enter the U.S. venture capital industry, said Heesen. “Despite the fodder, we do not anticipate massive failures of limited partners to make capital calls. Many will sell their positions on the secondary market out of necessity. Yet, that will just change
the mix and allow other institutional investors access to funds they could not access in prior cycles. High quality venture firms will be adequately funded going forward.”

Perfect – gTrade is designed to allow institutional investors and regular investors (you & me) connect with the businesses that need the startup funds.  We are then able to use our collective knowledge to value and assess the likelihood of success for these startups, and support then financially and morally.

The larger and more critical issue as I see it, is the liquidity issue with current and future VC funding – which simply doesn’t exist. “An overwhelming number of venture capitalists (72 percent) do not expect the IPO market to re-open for  portfolio companies until 2010 or beyond.  A more optimistic 18 percent see the market opening in the fourth quarter of 2009.  While venture-backed acquisition volume is expected by 57 percent of venture capitalists to remain the same or increase, 87 percent of respondents predict that acquisition transaction value will decline.”

With exits getting more and more difficult, so in turn does entry.  The capital that would otherwise cycle around the VC market from matured startup to emerging startup is just not happening.  We at gTrade are addressing this issue directly – there is no need to exit the market.  By trading in a free market, there is no need or requirement to exit immediately – institutional investors and regular investors alike can exit and enter investment as they see fit.

So as you can see gTrade has been predicting for some time now what the NVCA is now predicting for 2009 and beyond – it feels good to finally have some support from a large industry body.  We are hoping this will be the catalyst for existing, and maybe is some way monolithic, venture capital funds to come to the party – the gTrade party – for the new way to raise and trade venture capital.  This may just be the saving grace for the current VC market.